coaching and training for adopting agile and scrum
Posted in Agile Success, Project Management

On Relative and Absolute Quality

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.

LEARN MORE
Posted in Agile Success, Scrum

About the Role of ScrumMaster

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 from the sidelines.

LEARN MORE
Posted in Agile Success, Organisations

What Has Nokia Done Right and Wrong?

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).

LEARN MORE
Posted in Agile, Agile Success, Scrum

PDCA Cycles and Scrum

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.

LEARN MORE
Posted in Agile, Agile Success, Scrum

Two Types of Scrum

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.

LEARN MORE
Posted in Other

What I Really Want to Do

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.

LEARN MORE
Posted in Agile Success, Project Management

Your Greatest Risk Is Poor Project Leadership

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.

LEARN MORE
Posted in Agile Success, Scrum

TIEKE Brief #10 on Agile

Last Tuesday, on 4th of May, 2010, 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.

LEARN MORE
1 2 3