When we bought our house my wife and I got a common understanding of what what a “MVH” (the minumum viable house ) means to us. Which features are crucial, which are exciters, what do we need to move in, what can we do afterwards. We also did not commit to a special place to live, but to the conditions it has to fulfill and its priorities: kindergarten, medical attendance,  noise, nature, length of way to work, public transportation, school, shopping facilities, maximum price. By that way we found a new home where the whole family feels comfortable, even with the mortgage conditions.

Recently I had to run an underground cable 30 meters across my garden. Again I wondered about what “value” would mean to me, especially because my time was limited and it was not foreseeable that I would have been done in one day. An open trench across my garden for two weeks would have been waste. So I did it iteratively in chunks of about 3 meters. Excavating, putting in the cable, filling up. This way we can use the garden all the time and I had no stress with the work.

We try to find the last responsible moment to commit to questions in our live. For example which group our son will visit in the kindergarten when he turns three. Or if and when we do a vacation trip this year. Which birthday parties and/or weddings we do attend. And much more.

We did not assign special housework tasks to family members, but pull instead what is most important. Also at the last responsible moment (right before the family drops by) That works out pretty well and reduces stress for us all because of “unfinished duties”.

It’s really interesting for me to see how these principles simplify my live, at work as well as at home.

However: we played the famous Kanban Pizza Game, invented by agile42. This game helps you to find out how Kanban feels like during creating Pizza slices with various toppings. It was a heck lot of fun to play, reflect, and improve the way to a maximum of delicous pizza and a minimum of wasted material, together with my colleagues Daniel and Camille, and my dear friend and Agile companion Olli.

ETH & KU

Content from Kanban Pizza Game @ ScrumTisch May 2012

Marion took a video of the evening to create a pod cast from it, looking forward to watch it soon.

After finishing several rounds of pizza creation most attendees were hungry enough to switch to real pizza (or pasta, or salads) as well as interesting personal conversations. Many thanks to Marion, Ralf, Olaf, and the other guys from agile42 for this amazing evening!

“We want to introduce Scrum in our team, too, to get a feeling what is really ment by ‘working Agile’. Can you coach us?”

In my eyes this is really great, because it shows these guys don’t want to just talk – but act! So we organized a first workshop together with them to clarify some points:

• What does work look like in the HR world? How do “packages” of work look like? How planneable is their work?
• How do they collaborate? Do they after all? Are they a team? Can they support each other – or are they just a bunch of specialists?
• How do they recognize progress? What means progress? How much time are they waiting for feedback or external dependencies? How much stuff do they handle in parallel?
• What do they expect from shifting their work mode to Agile? Internally (within the team) and externally (to the rest of the company)? What does transparency mean to them? How important is it? And how possible, regarding sensitive personal data?

It turned out that

• There are long-running “projects”, like introducing 360° feedback, Agile management and leadership clarification, setting up exchange programes, just to name a few, coupled with daily business like personell talks, recruiting, contract stuff etc. Large projects can be broken down into smaller tasks and maybe also distributed over various team members.
• Currently the specialists view dominates, but the HR teams appreciates the idea of getting generalistic enough to take over tasks of other people. Especially in cases of sickness, vacation, or other absence of colleagues – or if there’s a huge work load.
• Definition of progress and progress tracking are difficult at the moment because they are missing an understandable common view of their overall work. It feels like a lot of time is spent waiting for external dependencies. An information radiator would help them to get a better undestanding of their work load, progress, and bottlenecks.
• The HR team expects improved understanding of their internal collaboration, a better defined task structure, improvements for their work flows. Transparency regarding the progress of long-term projects for everybody in the company would also be great.

At the end the HR team agreed to start with

• a daily standup
• regular retrospectives, facilitated by a ScrumMaster
• and a regular review to share their progress with the company.
• Mid-term they want to think about how to break down their work packages into tasks and designing/using a task board for visualization.

I’m looking forward on their experiences because I’m heavily convinced that Agile principles and practices can help also non-IT teams to improve their collaboration and productivity.

The attendees where variegated, including our CTO, senior directors, product owners, developers, ScrumMasters, HR people. The most controversial discussion was about understanding of roles and leadership. A powerful tool introduced by André was to skip the classic thinking of the roles in an organization as a top-to-bottom hierarchy of power instead of increased radiuses of competency:

Classic View: Organization Top-To-Bottom

Organization as Radiuses of Competency

This is really helpful to think further about roles and expectations and clarify rights and responsibilities. That will be the next big step for our company because it is the basic for a lot of other topics, like career paths, recruiting, salary, management style, and much more.

As this is also kind of my attitude I really like this approach. Especially in situations where there is a lot of improvement work ahead it helps people to take a step back and realize what they already achieved.

I tried the solution focussed approach in one of my last retrospectives, which I structured like that:

1. Locate Strengths
Locate Strengths is an interview technique. Two to three people interview each other for two minutes each about some given questions. In my case I chose “What went well in the last two weeks?” and “If you had three wishes for the next sprint – which would that be?” They take notes which will be presented afterwards.

2. Scaling Highlights
The participants reflect over a perfect future. In my case this was the perfect working product development process, including prototyping, direct customer exposure, and truely agile development. The people think about where they feel themself currently standing, on a scale from zero to ten. They line up on the according positions on an imaginary scale in the room.

Everybody tells, why he thinks he already reached this position (and is not at zero anymore). And he tells what would be the next, small step towards ten.

3. Appreciate Resources
This is a technique from Dana’s & Esther’s famous retrospectives book: Everybody writes his name and a personal task s/he will accomplish in the next sprint – to move further to the perfect future – on a piece of paper. Everybody’s sheet is moved around to the other participants. Every participant writes down the strengths he sees by the person who committed to a task that will help her to achieve her goal.

The format worked pretty well. We got a lot of positive energy from that. And: we got action items people feel personally responsible for. This was an idea Rob also pointed out. My personal upshot: I will use the solution focus approach regularly in my retrospectives.

After attending the workshop I must admit: it was kind of eye-opening and Marty is a really amazing (and experienced) guy. He focuses on building the “product company”, creating and monetizing great products for (and with) your customers. For me this was a great experience because as I have a strong technical background, coming from the engineering world, I missed the product view a bit. And I learned a lot in these two days, about how complex, inspiring, tough, creative, satisfying, and overwhelming excellent product management is. Kudos to all the good product owners out there! And what turned out: Marty’s mindset is truely Agile.

What hit me most was the concept of product discovery: sorting the ideas worth building out of a whole bunch of others. Marty claimed, Google is excellent at this, coming from 2000 potential ideas per year down to 500 they actually build. This may be a basic concept – but for me it was eye-opening. Don’t build any idea you think it is worth it – but collect reliable data about if your customers like your ideas before you actually start building.

The second great learning for me were his ten key points for building a product culture:

1. Obsess Over Your Customers
2. Distinguish Vision From Illusion
3. Define Success
4. Embrace User Experience
5. Fail Fast
6. Ensure True Collaboration
7. Improve Fast
8. Be Agile
9. Demand Excellence
10. Create A Culture Of Innovation

I think our company got a lot of insights from this event and I hope we will strive together for a true, successfull product culture. And I warmly recommend to talk to Marty for everybody who want’s to be a successful product organization.

First important thing to keep in mind: If you work on a problem – complete it. Don’t start too many things in parallel, just finish your work. This may remind you of things like the “One user story – whole team” advice in Srum or the WIP limits in Kanban.

Next remark: Step back and think about where you can actually set balls rolling. Where can you act on your own? Where do you need sponsorship/empowerment from your management? Where do you need to get stakeholders on board (and who are these stakeholders)? And finally: where should you just delegate the work and point to issues in a consultative way?

Our ScrumMaster team did exactly this to sharpen our mission and our self-understanding. We analyzed the organizations complete value stream from project idea submission to live releasing and nailed down the problems or improvement possibilities for each step in the workflow. Afterwards we became clear for which parts of the workflow we can take over the responsibility in a realistic way. We considered how much time we have (besides the work with our development teams) as well as the responsibilities of other divisions in the organization. The current result for us: we focus on the way from team staffing over product discovery and development up to the live release. For the rest of the whole workflow (things like project prioritization, or KPI monitoring) we may assist by providing helpful input – but are unable to really rock things under current conditions.

If you wonder how a team of ScrumMasters organizes itself here is how: simply by using a task board.

This is really great. We introduced the board since our team was growing. It brings real value by supporting visualization of all the tasks we did commit to and aiming on the important targets. We don’t track our “daily business”, the work with our Scrum teams, but all the stuff around that could be summarized as impediment removal and “organizational development”, bringing our company forward on the road to Agility and powerful collaboration.

By the way: we don’t work iteratively but Kanban style, gaining higher flexibility for dealing with the daily surprises.

But this is just a compromise – and not even a good one. Assume that we have teams that didn’t already reache the state of hyper-productive, high performant, self reflective Agile-evangelistic developers.

So – what does a busy ScrumMaster miss, if s/he can’t look at only one team?

• Developers try to solve problems on their own for a long time, trapped by their ego, instead of asking for help.
• People don’t ask the experienced guys for help.
• Discussions between team members are unproductive.
• Impediments will be accepted as they are instead of solving them.
• Questions will not be clarified together with the PO.

There may be more such things – common for all: they hinder optimum performance. And the question emerges: “Why does this take so long in this team? Is this normal?” Maybe it isn’t (depends on what is normal). But surely there is room for improvement. If the chances are recognized.

So the advice “one team per ScrumMaster” has its clear right to exist. If this is not possible the challenge is to organize your work as ScrumMaster to achieve best possible results. Maybe you are able to sit one sprint next to one of your teams and the next sprint next to the other. And maybe you can manage it to stay with your team at least a complete day per sprint to observe how the work together. But don’t miss the chance to get deeper insight into their work.

Tonio Lucca created a nice prezi on that, with some impressive math foo, wich I may warmly recommend:

Here are some possible approaches:

1. A certain, fixed, amount of time per iteration will be reserved for maintenance work, let’s say 10%.

Pro: At a first glance it looks reasonable – and above all “easy to schedule” from a classic management perspective.

Contra: At a second glance this approach leads to the need for task switching during a sprint. And as we know multitasking has a remarkably negative impact on productivity. This problem potentiates if you got a “maintenance batch” that is too large to fit into the 10% budget. So you would need to discontinue the maintenance work until the next sprint – or you simply may get into trouble delivering the promised product increment.

2. A variable maintenance time budget, negotiated for every sprint.

Pro: You earn higher flexibility to deal with variable complexity of maintenance work what should lead to higher predictability for your product development.

Contra: You still run into task switching issues and the maintenance work may affect your product development work.

3. Doing pure maintenance iterations.

Pro: You clearly separate maintenance work from new product development. People can focus on one theme at a time.

Contra: What if urgent maintenance has to be done during a product development sprint?

4. Have a maintenance team for a longer period of time. Rotate it afterwards to spread knowledge and avoid potential demotivation with the maintenance guys.

Pro: No task switching, no product development interference (you may be able to negotiate the time for the team rotation).

Contra: Need for all necessary domain and technical knowledge in the maintenance team. But this should build up if you use the approach for longer.

But a more fundamental question should be: what exactly is maintenance work for you? Bugfixes? Improvements? Because from the answer new aspects may open up – e.g. to think about a “zero defects” strategy or your application lifecycle management.

It rocks!

Why?

Because it made me think lot. And it helped me to understand observations in my work environment. And I found verification for ideas and approaches I’m following. So it’s finally a good mixture I think.

Moreover it is the most complete collection of scientific background information connecting (Agile) software development and complexity theory. You wonder why change feels so hard? Here you are! Lack of motivation? Got an idea! What about these useless managers? Well – they are more usefull than you ever thought! Why start thumb blondes suddenly selling self-written books with great success? Can tell you! Your book backlog runs out of items? Just turn to the end of the book!

Aside nobody can impute a lack of humor on Jurgen. Want a sample?

“I’ve seen ‘Agile’ tools that were less agile than Kim Jong-il stuck in a glacier.”

So what does this mean in sum? The book gets my unlimited reading recommendation. But assure that the right people read it, though. Remember: it’s called “Management 3.0″.

The best evidence I’m not wrong may be the foreword by Uncle Bob (Martin):

“I hate management books. [...] They sit on my shelves. I sometimes read them in the John.”

But anyhow he wrote a foreword for this one. Find out why – just start reading! And once again: be sure the right people get hold of it

So the 1.000.000 Euro question is: how do you organize your teams to avoid ending up with a totally messed up technology stack?

Basically there are two approaches widely known: either you focus on component (a.k.a. layer/technology) teams, working “horizontally” in a layer, or on feature (a.k.a product/project) teams, working “vertical” through all layers.

Granted we speak about truely cross-functional teams, having all skills needed to do their best job in their fields, each of these approaches has its strengths and weaknesses:

As you see, neither is the right answer. In the Agile community the tendency seems to lead towards feature teams at a first glance. They promise fast delivery of customer value, setteled on virtues like collaboration, communication, and the pursuit of personal enhancement. But from my experience in a distributed, complex enterprise architecture developers tend to prefer the component team approach to care for their babies.

The question is: how to get the best from both sides (or eliminate the drawbacks)?

Well, let’s take a look at another “Agile” approach for spreading knowledge and driving innovation within a company: Communities of Practice. A self-organizing group of people sharing a craft, an interest, and/or a profession. So wouldn’t that be a possible tool to solve the conflict between great architecture and high value delivery?

I think so.

The idea is to keep feature teams but encourage the members having the skills and interests in maintaining and developing a technology layer to actively participate in an appropriate Community of Practice. The duty of this comunity is to assure a clean, maintainable, reliable architecture over a whole layer, striving for improvements – yet always keeping in mind that the user basically doesn’t care about awesome technology in a layer but about great, functional, working features he can use.

One more word on this Community of Practice thing. I heard people saying “It’s pointless. We didn’t see any valueable output from many of our communities.” Most times this came from the (middle) management. Well – I think it’s the duty of even this management to assure valueable output of such a community. By setting contraints and expectations, by supervising progress and results, by creating good working conditions for the community. Despite you need committed, self-disciplined people for producing great value.

Enjoy!