“How Does Agile Make Me a Better Developer?”

3.4.2012 by
In this blog post, I’ll share a bit of a conversation I was having with a participant of my CSM course, who had his team ask provoking questions. I’ll share the questions and my responses. Remember that this is a conversation piece, so I can’t guarantee it’s more than opinions :).
Snippety snip, start the email here (the participants text in blue, my response in black):
> I had a great retrospective with the team that was having buy-in
> issues last week and they expressed some fundamental questions
> that they had not been given answers to.

There are no single answers, but I’ll try to give some possible perspectives.

> How does Agile make me a better developer?

Well, “Agile” doesn’t :). But I guess that’s twisting words :/. I guess by “Agile” they mean the combination of all three layers – mindset, control framework, and practices & tools. So let’s take Agile as that.

Still, I feel the answer is “no”. It is they themselves who make them better developers, by learning a new consistent framework they can choose to use when they feel it delivers higher value. Yes, there are many people who swear by Agile approach, because it let’s them deliver much higher quality code, deliver it faster, spend much less time debugging, and having fun working with a close-knit group of colleagues towards a meaningful shared goal. Yes, that is available to almost anyone who wants to continually improve themselves. No, it doesn’t come for free – they have to put themselves to learning it.

Also, as a point of view, as the number of people who can write virtually error-free code on first pass and deliver highly maintainable code effectively, that skill level turns from competitive advantage to pre-requisite in the next, say, ten years. Having only traditional skillset, conversely, turns from still competitive (because employers don’t still know much better) to competitive disadvantage. I mean, I would not hire a person who didn’t know how to deliver Agile code, or would not be willing to put themselves to learning it.

> How does this process make me happier in my Job?

The “process” doesn’t, again :). Badly done Agile will make their lives miserable, because it will take the old framework, and add expectations of doing faster and more on top of it.

If the environment is set up to support Agile, that is, there are managers who allow (and support) the team to self-organized, participate actively in removing impediments, assign sufficient authority to a PO who can take ownership of the direction, give the SM sufficient time and support to focus on the role, etc., then the team can focus on learning to do proper Agile at technical level and to learn working together as a cross-functional team.

There usually is a period where it gets worse before it starts getting better. XP requires focus and commitment, and practice. TDD will be difficult at first, especially if there is legacy code which is not supportive of code level testing. Pair programming will feel awkward until skill & knowledge levels start to level a bit. Continuous integration and test automation will require learning new skills and establishing new tools, until they start to show benefit by allowing faster feedback on errors.

I recommend the team, assuming they want to go for XP and Agile, to set themselves a two month period where they focus primarily on the process and learning to do it properly. Delivering features is secondary (though not irrelevant). Speed will come naturally. Make sure that your management understands the team’s need for learning new ways and grant them the time. If all goes well, after two months they will be where they would’ve been without XP, but now with a faster process, better collaboration, more shared knowledge, and, likely, happier people. No guarantees, but that’s what I often see and hear. 🙂

But if Agile is supported by organization (or benevolently “allowed” and not actively prevented), it does increase the amount of autonomy and mastery in the work. If you have a good PO, it will also increase the purpose of the work. And those are the secret sauce of motivation.

> What Defines “Productive” for a Developer in the Agile way of thinking?

Shortly, the team has a greater capacity to deliver value to PO and customers. This may be numbers (in terms of features), technical quality, or feature value. Ideally, it is a combination of all three.

Also, we should get rid of the idea of individual productivity and look at the team level. Traditional approach is very poor at leveraging collaborative effort – the power of teams. For people who have not been in a real team, they don’t know what they are missing from their professional life. “Aren’t you curious?”

End of the snippety snip part.

As the reader of this post, what elements would add (or modify) to my above comments?


On Relative and Absolute Quality

18.2.2012 by

I sometimes struggle between relative and absolute quality, and how they affect the way we work in businesses and the success we gain. That is, I really would like to think we should strive for better outcomes as a kind of value on its own (and merit from that as business success), but I so much more see “being better than competition” as “sufficient” for most people (and frankly, it is good enough for many companies to stay in business).

In practice, the questions boils down to “we’re already better than our competition, why over-invest?” The way I hear that is “let’s cash in on our advantage now, until we lose it”. I also hear “let’s gain in short term, and figure out long-term competitiveness later”. And I can see the logic in that. But it’s the same logic that has effectively crippled so many companies and destroyed their long term profitability.

I recall reading somewhere that the founder of Ikea, Ingvar Kamprad, once said that “the worst thing that could happen to Ikea would be to go public.” He was referring to the tendency of publicly traded companies to focus on short term outcomes and shareholder value over any other business priorities. While I’m no fan of Ikea, I can appreciate the success they have built (and yea, some few of the items they have designed have appealed also to me). And I can appreciate the mindset.

So is focusing on relative quality subscribing to short term thinking (and, as I believe, to sacrificing long term success)? The idealist in me says yes; the pragmatist accepts it as a short term goal as long as it is recognized for what it is.

So what would absolute quality look like in, say, subcontracting business? How would a company striving for absolute quality approach their goal differently from a company that is satisfied being just better than direct competition?

I’ve tried to give this some thought. I’ve so far identified the following dimensions:

  • Excelling in delivering customer value, exceeding customer expectations
  • Seeking to continually improve their development practices, to deliver error free solutions on the first go and remove all types of waste in the way they develop
  • Seeking to build their people to be self-driven, capable of taking initiative, and having satisfying professional growth
  • Looking inside to compare themselves to their past selves, instead of looking out to compare to others

Curiously, the first three loosely match the three characteristics of Radical Management – delighting customers, deep job satisfaction, and relentless improvement. The last one relates to one of the key characteristics of Performing teams – dedication to not accept sub-par performance from oneselves or team mates.

I’ll try to explore each of those dimensions to share what I feel about them. I’ve added some concrete ideas at the end of each dimension.

Excelling in delivering customer value to me is to seek the real value the customer _really_ needs, rather than seeking to deliver what the customer believes they want. It is not saying “well, you don’t know what you want, let me show you” but recognition that we (that is, both the customer and us) don’t have the possibility of defining “maximal” value up front. Only through successive iteration and revision of our understanding we are capable of finding what is really the most valuable bit, and then focusing on delivering that as effectively as it can be done. It is also recognizing that we may often have to challenged establish “truths” to discover new avenues for innovative solutions. The company doing the above is challenging established practices in IT subcontracting industry, and will have to build demand (and appreciation) for their approach. They will not be asked for it, they have to find the way to do it first within the constraints of current business practices.

  • Implement “Money for Nothing, Change for Free” in all customer contracts, and help customers to actually take advantage of it, even if they didn’t ask for it originally.
  • Seek to understand what the customer really wants by demonstrating progress continually and asking for feedback, then feed this back to customer’s decision-making processes for action
  • Teach customers of the benefits of iterative and incremental approaches, what is the value to _them_.

Continually seeking to improve the development practices involves all levels of their operation, starting from the technical practices, to project leadership, organizational management, and internal operation. Internally, they should be challenging themselves continually, seeking impediments to delivery at all levels, and relentlessly seeking to eradicate them. And to understand that this all is normal operation of the organization, and not an “improvement initiative”.

  • Deploy full-time ScrumMasters to all teams and at different levels of the organization
  • Use “technical excellence programs” to keep people learning better ways all the time, e.g. through internal coaching
  • Use metrics that reveal waste and bad quality, and feed the results back directly to teams and individuals
  • Encourage people to learn outside their typical domain
  • Build careers around technical excellence, so that we don’t lose more great developers to ranks of bad managers

I believe that people excel only when given sufficient authority to do a great job. There are examples of organizations that have done exactly that, and their people have delivered outstanding outcomes. A necessary condition is access to information. To really drive self-organization into the organization, information must be made easily accessible (and pushed) to everyone in the organization. Doesn’t matter who. And this is a challenge, for sure. Not just overcoming the culture of “information on a need-to-know basis”, but also providing that information in a way that is digestible and creating the skills to using that info for everyone. Only then can we start expecting people to make good system-wide decisions about their work and take real ownership of it.

  • People are trusted and external post-decision authorization is kept to a minimum
  • Teams know their P&L, but also that of their neighboring teams and groups at different levels
  • Progress is made clearly visible to everyone interested, through demos and clear communication approaches
  • People are held accountable for their decisions and must personally justify them when challenged – people are taught how to evaluate the value of their idea before committing and also recommended to verify those with colleagues

The desire to look within rather than compare to outside is important to maintain momentum. Any company doing that will realize that improvement is never-ending and that there are always ways to get better. But if we compare to outside parties, it’s easy to get satisfied with the results and become complacent. That doesn’t naturally mean that we forget the outside world, but only that our primary competitor is ourselves.

  • Maintain metrics showing improvement in operation, but try to make sure the metric is open-ended and doesn’t have a “cap”, if possible.
  • Measure the amount of improvements in the organization and have warning levels when they go too low
  • Continually allocate attention to the need of getting better, celebrate successes

To summarize, if I look around at many of the successful companies (e.g. Toyota, Apple…), I see these ideas, at least in many ways, being deployed. Excellence cannot be achieved by being satisfied with good. We should celebrate when we progress, but never satisfy ourselves with it.

The Color of “Scrum”

17.2.2012 by

While at it, let’s write another post – on a less serious topic. About a week ago, while training, I realized that if I had to choose a color to write the word “Scrum” with, it would most likely be red.

Then I started thinking why.

I guess it has to do with the passion I view Scrum with. I think there is a lot of emotional aspects to Scrum – the success of delivering value, of exceeding expectations, the camaraderie and working towards shared goals, etc. It’s also a color associated with speed and power (at least in Ferraris).

But red is also often perceived as the color for danger or the negative. So I find it quite interesting that this color felt the most natural for a thing I see as nothing but.

Interesting indeed.

What is the color of your “Scrum”?

About the Role of ScrumMaster

17.2.2012 by

I’ve been too busy for too long to write blog posts, but here’s one, about the role and authority of the ScrumMaster.

The way I understand the Scrum framework is that the ScrumMaster is the person who does have a lot of authority over the process, but in the same way as in any other matter – everyone in the team is responsible for their own work. I don’t see how ScrumMaster has any authority to say anyone in the team that they must work in a certain way. He/she can certainly talk about the process, educate about better ways of doing it, showing where the process currently fails, etc., but I believe every single person in the team is responsible for the way they do their work.

This is not unlike in a soccer team – the coach does train the people, help them practice to become better soccer players, have a vision how the team should/could work together better, suggest better strategies, BUT when the game is on, the players are responsible for playing the game. I don’t know any single soccer game where the coach scored a single goal.

Similarly, if the team performs badly, I would first look at the coach and try to find out what that person did to improve team performance. However, if I determine that that person has done his/her best, then he/she is innocent, and we need to look at the players themselves. Did they do their best? Do they have the right skills to play at that level? Are they practicing on their own time to improve their game play and ball handling skills? It might be necessary to change the composition of the team to match what is needed.

Furthermore, I really appreciate the fact that the team makes their own “rules” and holds all team members accountable to one another for following said agreements. It is not the SM who they are accountable to. So if someone doesn’t work the way it was agreed, they need to explain their way of working to other team members, not the SM.

So, I see ScrumMaster as a strength of the process, compared to almost any other framework around. Finally we have a person who is free to take a bigger look at things, to optimize the whole (along with the help of everyone else in actually making it happen). Finally someone is free from the pressure to deliver and to think of better ways of developing software and removing the blockages. And this freedom, I’ve found, is central to being a great SM. As soon as you dip you toes in the content (i.e. delivering something), it will draw you in like a siren and you will lose the external viewpoint. I’ve been there, I know how attracting it is to participate in finding the solution to the challenge.

I saw this happen in a customer organization that I visited about a year ago. Originally, they had SM’s who were part time members of the development teams. As a result, those SM’s only had time, focus and energy for the “ScrumSecretary” role. As a consequence, the Scrum implementation in that organization was lacking the spirit. It was doing the motions only. After switching to five part-timers to three full-time SM’s, things started changing. SM’s started working on the bigger picture, work with teams better to improve their work, and generally work the environment. As a consequence, over the next eight months quality improved, people became more energized and focused, and also the amount of output increased to double the original.

What Has Nokia Done Right and Wrong?

11.2.2011 by

A colleague asked me very recently, regarding Nokia being in the headlines with Elop’s recent internal memo, what has, in my opinion, Nokia done right and wrong over these years. After all, they achieved a massively dominant position in mobile phones and are now losing it all.


I think they did a lot of things right in the late 1990’s and very early 2000’s.

They were the first ones to focus on customer experience. Even if the processes weren’t very refined compared to best practices today, Nokia phones were considered to be the easiest to use for almost a decade (until iPhone hit the market).

They were very good at logistics and manufacturing tens and hundreds of millions of phones. They won the cost race (and it’s the area they are still very strong, although Elop did mention pressure from Chinese now).

Symbian was a very good platform when resources (energy, memory, processing power primarily) were scarce on phones. Since it goes very close to hardware level (being C++ code), it is possible to control resource use better than in any other environment. Now that none of those things are scarce, it is too difficult and time consuming to develop anything in Symbian (against competition on iOS and Android environments).

Nokia has been focusing a lot on technical specifications (in true Finnish mentality), and many of their products are still technically superior to their competitors. Unfortunately, that was a significant competitive advantage only until iPhone changed the game.

Nokia used to have a lot of really really excellent people. Unfortunately for them, so many of them have effectively been driven out of the company by their unfortunate policies and culture.

In late 1990’s and early 2000’s, Nokia was full of “winner mentality”. They were successful and they were revolutionizing the world. They were the ones who made mobile communication so pervasive as it is today. That elevating goal was driving people and there was a lot of shared commitment to becoming and being excellent. The success and high morale was naturally masking many of the dysfunctions of the organization, which then started hurting the company when they were no longer cruising as the sole winners of the world.


Things they did wrong, in my humble opinion

Nokia has a pervasive attitude that creating software is very much like production. Unfortunately, nothing could be further from the truth. Production can be charactized as “same at lower price”, whereas development is “more value faster at any cost”, although “any cost” should be considered as a smart investment against expected returns. Product development is a brains game, and the best brains are costly. However, their value/cost ratio is still much better than for less excellent brains, making them still a very good deal. The Nokia attitude unfortunately discounted the value of good brains, and mistakenly considered low cost development “resources” as a good deal for them.

In this quest to lower prices, they effectively killed their brain-based subcontractors. In the stranglehold, no suppliers were able to pay for their good employees appropriately and keep them developing software for Nokia. If someone tried to maintain reasonable cost structure, Nokia cut off purchasing from them. So in their selfish greed, they effectively cut themselves off from talent and brains.

Also in their quest to lower prices, they moved to India and China with entirely wrong goals and strategy. Therefore, the code quality in Symbian is horrible and they can’t really even keep the system stable anymore. Will they do the same in Meego? Or is that the reason Meego is delivering value much slower than it should to save Nokia?

Their management organization is very bonus driven and hierarchical. People were much more interested in getting their bonus checks than caring for greater good within Nokia. If helping someone else needed compromising one’s bonus goals, the help wouldn’t really happen. Add to that the fact that often these bonus goals were misguided (see above), the effect was often really bad.

Nokia was very focused on measuring individuals and their performance, and driving “performance” with the above mentioned bonus systems. Anyone who’s seen http://www.ted.com/talks/dan_pink_on_motivation.html or read about the topic, should know that external motivator (like bonuses and carrots/sticks) are actually harmful for intellectual work, reducing people’s capability for innovation. Plus they kill the grounds for collaboration for common good.

They were constantly reorganizing, effectively preventing the formation of stable teams. Stability is pretty fundamental for high performing teams. You need to know who you work with, what are their capabilities, and learn how to work together to best benefit from each others’ talents.

In their drive to “low cost option”, they are constantly creating distributed teams and making it very difficult for people to communicate and collaborate effectively. While there are good reasons why you sometimes have to distribute a project, more often it was just in the illusionary quest for “low cost”. I hope I’ve established that quest for low cost -> low quality -> high cost or low value. 😦  (the Agile alternative is quest for value and quality -> high speed -> low cost [and not just in relative sense]).

I think it was necessary to change leadership in the company. I’ve not had any confidence in the management of Nokia for the last 5 years. Elop may be the saving grace, but we’ll yet see. He has a massive problem at his hands and a single person may not be enough. I don’t even know if he has the right ideas, but at least he was pretty frank about Nokia’s problems, so I do hope he can turn the ship away from the shoals.

I’m sure there are more good and bad things than those alone, but that’s the best I can do right now. Please add your insights to comments!!

Scrum vs Waterfall in Five Words

26.11.2010 by

On a CSPO course today, I got the following “question” from the participants:

“Benefits of Scrum vs. waterfall in 5 words”

🙂 Never had to put so concise.

So here’s my try:






Not a statement, but five words nonetheless.

But those weren’t the first five words that came to my mind. The first was:

“Scrum projects kick waterfall’s ass”

Not the most politically correct, though :).

But the whole topic is a bit unfair. It’s like asking the benefits of shoes vs. gloves for your feet. This isn’t really a question should we use waterfall or Agile for a software project, because both processes are valid in appropriate process context. Plan-driven approaches are highly valid for predictable environment whereas Agile is for complex environments. Also, there are situations where significant pre-planning is just necessary, because of excessively long feedback cycle or massive rework costs.

Mike Cohn, in his recent book “Succeeding with Agile”, poses this issue as a balance between “anticipation” and “adaptation”. In every situation, we do at least a little bit of anticipation and a little bit of adaptation. How much of each we do beyond that depends entirely on what we are doing. If we are ordering an expensive server with a couple of month’s delivery time, it probably makes sense to do your homework in advance. The only trouble with traditional thinking is that it does not sufficiently recognize the need for adaptation because of the expectation that projects are fundamentally predictable (and claiming that we just don’t know enough of it yet).


What would have been your five words?

PDCA Cycles and Scrum

24.11.2010 by

Recently I “rediscovered” the PDCA cycle, made famous by W. Edward Deming, consisting of Plan, Do, Check and Act phases, and forming the base for every process improvement cycle. According to Wikipedia (http://en.wikipedia.org/wiki/PDCA):

PDCA (plan–do–check–act) is an iterative four-step problem-solving process typically used in business process improvement. It is also known as the Deming circle, Shewhart cycle, Deming cycle, Deming wheel, control circle or cycle, or plan–do–study–act (PDSA).

PLAN – Establish the objectives and processes necessary to deliver results in accordance with the expected output. By making the expected output the focus, it differs from other techniques in that the completeness and accuracy of the specification is also part of the improvement.

DO – Implement the new processes. Often on a small scale if possible.

CHECK – Measure the new processes and compare the results against the expected results to ascertain any differences.

ACT – Analyze the differences to determine their cause. Each will be part of either one or more of the P-D-C-A steps. Determine where to apply changes that will include improvement. When a pass through these four steps does not result in the need to improve, refine the scope to which PDCA is applied until there is a plan that involves improvement.

Does the above sound familiar? It should, because it’s describing Scrum’s control process, albeit with different labels. Essentially, Scrum is a “product improvement” cycle, with some additional stuff thrown in. In each Sprint, we establish the objectives and processes to deliver an improved version of a product, do it, check the results against expectations to learn about the direction and way of working, and seek to understand in which way the product or the development process should be taken towards next.

In fact, I just described two simultaneous cycles, one for product and one for process. And those are not the only ones, since we have daily cycles, release cycles, and many others depending on the actual processes we use.

However, the PDCA cycle provides us some insight into how we would benefit from Scrum more. An integral part of the PDCA cycle is measuring the output (or generally, evaluating it against some criteria) and comparing that to an established expectation. Setting such an expectation is not what I’ve observed in a grand majority of Scrum teams I’ve worked with (partly because I haven’t mentioned it, but partly because no-one else has, either).
For the knowledgeable reader, setting an expectation would be a no-brainer. And frankly, I’ve “known” it for ages. But the importance has escaped me, even if I’ve used the same principle in many other contexts. Acceptance criteria are one example. Commitment at the beginning of a Sprint is another. They are not always used in the same way, but the foundation is the same.

So why is setting an expectation so important (or at least useful)? The question reminds me of a marketing questionnaire exercise I did back in university. We took an issue, planned questions and ran the questionnaire, only to realize upon analysis that we really didn’t know how we could actually use the results. We had posed the questions in such ways that we could not draw any meaningful conclusions, because the questionnaire was lacking key questions or we had phrased the question wrong.

It is easy to fall into the similar trap in our retrospectives. We consider our options and agree some improvement actions. In the next retrospective, we return to the topic and evaluate if the change has had some impact. Except that we don’t really know. We get wishy-washy feelings one way or another. We had failed to establish an expectation and a way to measure results. Such unclarity is a bit demoralizing and it clouds the actual result. It is much more difficult to get people committed to improvement activities when there is no clear feedback about their effectiveness.

I will do my best to incorporate this insight into all retrospectives I run from now on. I will also try to pose these two questions into any other conversation regarding some improvements or changes:

  • What benefit or outcome do we expect out of this improvement/change?
  • How do we measure it?
  • Who is responsible for measuring it?

Ok, three questions.

Two Types of Scrum

10.8.2010 by

I’ve come to realize recently that there are two types of Scrum. One is goal-driven, the other is story-driven.

The Story-Driven Scrum

This approach seeks to identify and prioritize user stories (or any requirements) small enough to fit in the iterations. In these Sprints, the team commits to delivering the selected set of stories. These stories can be estimated and the amount of results can be measured for longer term planning. This approach works best when enough design work can be done in advance to eliminate most significant elements of uncertainty prior to committing to work in a Sprint. I could call this type the Mike Cohn Scrum as this approach is excellently defined in his Agile Estimation and Planning book.

The Goal-Driven Scrum

This approach sets a goal, or a problem or a challenge, for the team to solve during the sprint. The commitment is to solving the problem, not so much on the characteristics of this solution. The goals are harder to measure and therefore it is more difficult to gain information on the team performance for future planning, but the whole approach is geared toward research and problem solving, both of which are by nature impossible to estimate accurately. I could call this type Ken Schwaber Scrum, or maybe Takeuchi-Nonaka Scrum, as this approach was quite prevalent in the original Scrum texts and especially in the Takeuchi & Nonaka article The New New Product Development Game where Scrum was first described.

There is a lot of experience of story-driven Scrum in the world out there. Majority of Scrum implementations are of this type. However, I’ve recently come to perceive this approach as potentially the weaker type of Scrum. I guess I have to explain.

The power of Scrum is in transformation and innovation. The more cross-functional the Scrum team, the greater is its power for said innovation. The more leeway the team has in solving the problem, the greater is its potential for finding breakthrough solutions. The very extreme is the team described in The New New Product Development Game article that was given three months of time, full support, and the goal of developing a new product for the market. The team itself had all the expertise needed to understand the problem, explore solutions and deliver the goal.

The difficulty with goal-driven Scrums is that they require much more transformation from the organization than story-driven ones. Goal-driven Scrums force the involvement of most or all functions in an organization. Much more rapidly, the organization must face redesign of the way it works. I bet it will fail rapidly if the Agile values are not embraced at all levels and functions of the company.

The story-driven approach is much more-forgiving to the organization. In it, the development teams can be pretty much like development teams have been in the past, primarily consisting of software developers of various roles. They can also be fed quite similar problems (just transformed into stories). While doing that well will result in significant improvements in several ways, it still more easily allows sticking to old paradigms. All of this is obviously dysfunction, but that is not so apparent to many organizations.

When looking at most contemporary Scrum teams, they are typically quite homogenous in terms of skill sets and background (e.g. software developers). While there can still be significant differences between team members, we rarely see people with marketing, sales or domain expertise (except in the very good Scrum teams). The “Agile transformation” has been nicely constrained to the development group. As a result, these teams must receive pretty well-defined work. The capability to innovate entirely new solutions is very constrained.

Unfortunately, there isn’t a clear pattern how a goal-driven Scrum would operate. Many Scrum and Agile trainers don’t teach about its existence. I know I haven’t. I should, at least to open up minds to its existence, but I’m really short on time as it already is with the CSM course. There are so many topics already that adding that might prove impossible. Yet I think I should, somehow.

I believe the goal-driven Scrum would be instrumental in transforming organizations beyond product development.

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.