Mary Poppendieck – Leadership and Self-Organizing Teams – Incompatible or Synergistic?

• Leader’s job is to keep the team from their comfort zone!
  Too often – espeacially small – teams are aiming for consensus – leaving out most of the wisdom that individuals have. The leader has to ask unpleasant questions.
• What differentiates a team from a workgroup is ‘common purpose’.
  A workgroup or committee is a group of people doing work together – but they don’t necessarile have the same goal. A team by definition is a group of people working together towards a shared vision or goal – common purpose.
• Teams are dependant on their ability to make good decisions. And good decisions need:
  1) Diversity of opinions – all people participate in decision making
  2) Independence – team members may not be dependant on each other
  3) Decentralization – tema members are needed to have different specializations
  4) Aggregation – team must be able to draw conclusion from diverse opinions that come from different expertises
• Team need two kinds of leadership:
  Competence leadership – like a master teacher who tells you how to play violin
  Product champion- like a  band leader wo is guiding the whole group
• Competence leader assists in specialization while product champion helps in aggregation
• There are two types of management: 1) Mission command and 2) Detailed command
• In agile and lean development, mission command is what we need.
• Mission commanders job (leader) is to
  1) State intent
  2) Set the tone & tempo
  3) Make better people
  4) Improve the system
• Always consider the cultural aspects of any organization and remember that different countries have totally differnet biases on what’s acceptable and what’s not.
• When reading ANY theory, always consider in what country the author was raised up.
• Lean originates from Japan, Agile originates from US

Jim Coplien – Why Lean and Agile are in conflict, and how to resolve the conflicts

• Scrum is not about some fancy practises
• Even the much touted Nokia test doesn’t guarantee real, suscesful Scrum implementation
• Lean is meant to deal with complicated things while agile is meant to deal with complex things
• Productivity is actually waste! It causes queues and inventories. You need to concentrate on ROI and the flow of value through the whole stream
• Agile is about “doing just enough to get just enough quality” while lean is about “doing the least you can to achieve excellence”
• Irritating fact, that seems amazingly commonly to be surprise: A hope is not a plan.
• Scrum is not about 30% not even 100% of improvement. It’s about 2-3 orders of magnitude improvement when done correctly

Petri Heiramo – Scrum from the customer point of view

• First impressions: weird terminology and a little common ground
• Key benefits
  1) Improved communication
  2) Better visibility
  3) Enabling changing requirements
  4) Faster feedback
  5) Building quality in
  => Higher ROI
• Success and value cannot be managed through cost. Instead, focus on
  1) User research&business analysis
  2) Competence & motivation of team members
  3) Amount of knowledge generated in every iteration
  4) Ability to incorporate cost
  => Focus on value
• Research is completely different from development. You cannot estimate research.
• Start from the definion of value and aim only towards generating more of it
• Software should not be buyed be spec but by a vision instead.
• Buying on spec causes higher cost, lower value and loss of knowledge between different phases of the project
• You need continuous integration at project level, especially on multi-supplier projects
• Never fix scope on a contract, even if cost and duration are fixed
• Enable changes and early termination
• The finnish acquisiotion law actually do not state you need waterfall. It especially makes it possible to avoid so called “open conduct” and use a “negotiative conduct” instead whenever the nature of purchase is such that the requiremetns cannot be clearly stated beforehand.

Karl Scotland – Five steps to kanban

1. Map the value stream
2. Visualize it
3. Limit work in progress
4. Establish cadence (pull system doesn’t need timeboxing!)
5. Reduce the kanban tokens

• You need to keep the work flowing, not the workers busy
• Ideally, development of a new feature doesn’t start before customer has paid for it.
• Visualize the work in progress and gradually limit the number of work items in progress
• Ideally the whole team works on a single story all the time.

Ari Tikka – Understanding power

• ‘Power distance’ is an important aspect of everyday life
• It’s easy to be dependant on other people
  - The other will take care of me
  - I don’t have to decide
  => A tempting trap
• Use of power is often constraining the system. There are two types of constraining.
• Productive constraining. Like timeboxing – constrains the time axis
• Bad constraining. Like micro-management that amplifies power distance and adds friction. Or conflict avoidance, which results in weaker decisions.

Bonus Panel – why bother with agile?

The discussion went “a bit” off-topic, but interested discussion whatsoever

• Agility started from software development, now we need to get higher in the corporate culture
• Agile practises have worked long time, long before agile was a buzzword.
• The only companies that will survive are those capable of changing rapidly
• We are pretty good at looking into the future – but too often forget that the future will not stay the same!
  Also, we feel unpleasant to look back into the past – which is where we could learn
• Waterfall has itäs place and works in simple projects. Complex projects are where you need something more and agility may work. In chaotic circumstances nothing will survive.
• The biggest mistake we made was to plan year-long projects at the day-level detail.
• The trend is towards smaller teams, where everyone is required to participate in decision making. There’s no room for just hanging around.

Of course, you can follow what is going on on Twitter.

Technological competence – programmer

My Colleaque Jouni had a nice post about what you need to learn in coming year if you are a Microsoft developer. Another colleaque, Aki, posted a nice summary of what expertise every web developer should possess.

These are nice summaries, but they still leave a lot of important skills out. Aki’s post for example leaves the server-side untouched. Usually, you don’t write xhtml and css without some kind of server technology, be it Java, .NET, Php, Ruby, Python or whatever. Each of these technologies come with their own surroundings. Let’s take .NET (the one I know best), you need to know a language (C# for example), the web framework (ASP.NET, in web forms or mvc flavor, preferably both), the huge class library (BCL) etc. Sure, you need to be competent in some data access technology (like Entity Framework, NHibernate) and seldom do you make it without touching a DBMS (like Sql Server, Oracle etc).

And if you really want be a competent guy, you surely do make use of unit testing, inversion of control, be familiar with collaboration envinronments and configuration management systems, handle the application server and it’s configuration, …

From programmer to developer

After you handle all this, it merely makes you a decent programmer. Once you get there, you need to crasp a good understanding of development methogologies and patterns, have understanding of project management and teamwork, understand the basics of software business and handle all the numerous social occasions in front of angry customers you are thrown into when something has gone wrong.

Understand these things, and you’ll be a good software developer.

From developer to organizational champion

So the days of “pure C++ developer” are long gone. You need to handle multiple technologies and understand your craft thoroughly. And one of the biggest challenges to typical programmers is to accept that programming should be the last resort to solve a problem. Most often, there are better and cheaper solutions. And when you advance in your career from mere programmer, you begin to see more and more problems.

All this makes me wonder, what is the point in being in business like this? For me the answer is obvious: software development is all about learning. If you are not willing to learn, software development is not for you. If you love to learn stuff all the time, enjoy the neverending journey! And as correctly executed agile development emphasizes learning, it is perfect fit. And what does agile have to do with competence? Read on…

Cross-functional teams come from… multi-competent people!

Yes, you could make Scrum team from one tester, three programmers, one technical writer and one project manager. But do yo think a team like that would work efficiently? I guess not. Traditionally, each person has a stigma in her forehead: “I’m a tester”, “I’m a DBA” or so. My claim is that this very specialization is the biggest obstacle to productivity. I’ve way too often witnessed value streams that go like this:

1. Project manager (PM) listens to the customer (C)
2. PM tells the requirements to the programmer (P)
3. P implements the functionality
4. PM tells user interface designer (UID) the requirements
5. UID makes his part and notes that P should make some changes
6. PM tells P to make some changes
   …
7. Finally PM meets the C only to find out that both P and UID had implemented something that doesn’t please the C so let’s start from 2
   …
8. Repeat this cycle n times and start wondering, why we are not making profit.

If we had a perfect human in the sense that she had all the skills of PM, P and C there would undoubtedly be no problems (of course there would, but those could be solved immediately). But we do not have perfect humans, so we need to have people with different skill sets. So here is our formula to productivity: The more distinct the skill sets of team members, the lower the productivity will be. Or the converse: The more diverse skill sets team members possess, the more productive team will be.

As we know, each handoff to a different person needs knowledge transfer, which in turn is costly. And the more distinct skill sets, the more handoffs there will be. This can also be seen as the classic debate, generalists vs. specialists.

I’m not saying that there’s no use to specialized expertise. What I’m saying is that general competence should be the norm and specialists are extra. What did you learn today?