Until and unless folks learn to “pull” help, the coaching role is meaningless. A coach’s first priority, then, is to get folks to that place.

Bob Marshall

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!

So I pushed things forward and created a draft for a new “implementation” of the ALE network site at http://alenetwork.renemt.de

It is based on WordPress and the BuddyPress plugin, using the Custom Community Pro theme by Themekraft. The benefits of this approach are:

• sustainable, actively supported, open source technology base
• integrated group features, like LinkedIn
• forums possible with one click
• simple, clear constraints for structuring contents (=pages or posts)
• easy of use – WYSIWIG blogging style (not even Wiki syntax)
• simple styleable/themeable
• already nice-looking

alenetwork.eu - current state

alenetwork.renemt.de - Draft

So what I, what WE, need now is the help of the community. Some volunteers interested in helping to take over the missing content from the original page (mainly the country information and the ideas) – as well as to drive the technical development if needed. In short words: show the interest of the community in the new site.

So please – contact me!

The concept is rather simple: put all stories to be estimated on a table ordered and grouped by its effort. Afterwards you may assing a common story point value to each group. For more detailed instructions see here.

Some people claim that team estimation only works well if you have a lot of stories to estimate, for example if you need an initial estimation of a fresh backlog. But I found that it improved our sprint planning as well. Here is my explanation why:

1) People focus more on the story and its effort than on the numbers on the poker cards.
2) You see all stories and their rating at ones, making it easier to remember the relation between the efforts.
3) It encourages people to revise their estimation the more stories they estimate. I rarely saw a situation like “Well – let’s talk again about the estimation for this special story we pokered earlier.” But now there are often discussions like “Frankly fellows – look at these here. Does anyone seriously belive it is more complicated to do than that?” That’s great!
4) Even for people not so familiar with the context of some stories it is easier to understand how the more experienced see the effort as when they only stare on plain numbers.

So for us team estimation proved as a valuable tool.

A strange statement, most notably if it comes from someone who works in a company that claims to do Scrum since nearly two years. But this shows how hard the way to real understanding of agile really is.

Based on this I had a discussion on twitter lately. Declaring that I mostly hear about the problems to change from waterfall to agile – but that in my eyes moving from anarchy to agile is often a similar struggle I met some refusal. So let me explain:

On my journey through different companies I saw several, mainly startups, where initially happened what I call “anarchy”: the absence of a halfway regulated process covering the whole development lifecycle. Instead “work on call” was practiced – and everything that counted was to build a features. Quality was secondary. In this environment the valued developers were those which delivered fast what a project manager asked for (at which “fast” means to implement even unclear requirements and adapt them afterwards until they fit). Those were also the guys who made the rules they and their followers adhered to. As long as they delivered fast they could follow any rules they wanted. The responsibilities were clearly separated: project managers required features, programmers programmed, testers tested, IT released – and it was obvious who to blame if something failed.

And now you come with “agile”. And if it would not be enough with some even more concrete framework like Scrum. Suddenly it is no more adequate to be a good programmer. Suddenly it is secondary how fast you implement a feature – because the only interesting metric is how fast it goes live and delivers value to the customer. Suddenly you are to work in a team – and a great deal of your day falls apart for communication (same as product owner: you are not able to do “your work” anymore because you have to talk to so many people). You have to talk to people you may have never seen before: the guys from sales and marketing – or even the customer. Suddenly communication skills seem to count more than programming skills. Suddenly you are enforced to strive for improvement and not to live longer with the status quo. Suddenly there may emerge rules and practices you decline for yourself because in the past you never did it like that – and now the community says you have to. Suddenly not your personal work is measured anymore but what your team achieves.

This may feel like the loss of personal freedom. Especially for people who felt comfortable in the old days (where there was also not that much transparency). And depending on in which area these people work – development, quality assurance, product management, management etc. – they may oppose the changes in several ways for varying reasons with different influence and become cobblestones on the way to further improvement.

And this is it. While the way from waterfall to agile may be stamped by the fear of losing a known structure it is the fear of losing freedom when you come from anarchy. Your challenge is to deal this.

But you might remember your counterpart of his little child or maybe a kind of defective robot if you continously ask “WHY did you…?” “WHY do you think …?” “WHY do they…”

So the idea is to develop some creativity to ask “why” without using the word itself.

Imagine there is a manager who states “We definitely need to name a single person who ís responsible to coordinate all the releases!”

Some questions to ask “why” could look like this:

“Could you outline once again what problems we have with the releases?”

“What are we hoping the responsible person will help us?”

“Walk me through: How would she do her job?”

“So when she has all information, what happens then?”

“Help me see how this would make us faster?”

As you might have noticed we are using words like “we”, “our”, or “us” to signal that we both strive for a solution, lowering the feeling of justification for the proposal and opening the door for suggesting a different approach. Furthermore the conversation does not smell of a “technique” (some people may feel uncomfortable with this).

(Thanks to Jaynee Beach Lafferty for the inspiration.)

In few days will will re-launch our complete platform at zanox. While we normally are using Scrum for the product development we switched to Kanban for the last weeks before (and after) the launch after the “big” feature development was done so far. For what reason? Well,

• to be able to react flexible on upcoming issues
• to be able to distribute open task between all teams all days
• to get transparency on how done a task really is
• and because we had no real user stories anymore – but a lot of “polishing” issues

What we did

Whereas we had product teams working on separate product backlogs before to build the parts of the whole platform we now are using a common backlog over all teams. The work is distributed daily as teams have capacity so they don’t run out of tasks. Our workflow is quite conventional – but as we know “the more steps a workflow has the less value offers each single step”:

1. Open
   This initial status of a task, all open ones can be touched and reprioritized every time.
2. In Progress
   A team started working on this task.
3. Implemented
   The task has been implemented and tested in the development system.
4. Staging
   The work result has been successfully deployed on our staging system and can be reviewed there.
5. Live
   The  implementation went successfully live and can be checked for proper operation once again.
6. Done
   Yeah – finally mopped up the litte mofo brought home the bacon  

As we use Jira with GreenHopper as company-wide issue tracking system we also set up the workflow there. A nice side effect is that GreenHopper comes with some nice chart views to visualize the state of issues.

What we found out

Well, our company still fights with the hurdles of the agile transformation process. We know pretty well where our weak points are and our ScrumMasters and agile combatants state this very clearly every day (but are not sure how seriously we are finally taken by the management), striving for improvement.

In the morning the ScrumMasters went to their teams’ standups and spoke: “Team! The air is electric, things get rocking! Only a few days to go and still enough to do until we push the red button! So we adjusted our workflow a little bit to bring more transparency in how ‘done’ a task is at the moment and to help our testing crowd to put the stuff under fire a.s.a.p! We introduced the status ‘staging’ and ‘life’. That means: if you deploy things to staging or if releases go live please change the status of the corresponding issues.”

After this my ScrumMaster workmate came to me, grinding, and she quoted the following conversation she had with a team:

“… so please change the status of the corresponding issues.”
“But this is impossible!”
“Why?”
“Because the issues don’t go live on their own but in release packages for the corresponding projects!”
“Well – fine! So where is the problem?”
“We don’t know which issues are in a package!”
“So – why you don’t know? I mean: you build the package – so shouldn’t you know what’s in?”
“How should I know what my team-mate did!?”
“Err… could you please repeat this!?”

Following there took place some small repetition of the concept of human conversation – and what “individuals and interactions over processes and tools” in the agile manifesto may mean

Another aspect that crystallized out was the we had the same issue over all teams. As we have a SOA-based multi-tier architecture while developing vertically in cross-functional teams there are often made changes to one component by multiple teams at a time. So how is the releasing team able to find out who else touched a component with minimum effort? Means without running around and talking to 40 people or searching across the whole Jira or Subversion logs?

The solution was amazingly simple and – much to my delight – came from the teams itself. We use a (physical) “component board” where we have listed all components in the system. Whenever a developer implements an issue for this component she notes the ticket id on a sticker for this component on the board. If now somebody wants to release the component she simply takes the sticker and sees, what issues will be in the release and furthermore who she can ask for the state of the issues. So it is no problem anymore for the releasing team to set the state for all issues on deployment to the staging or live system.

So what happend? The simple introduction of two new (and valuable) workflow status made problems in our communication culture transparent immediately and thereby led to rapid improvements.

A second perception was that the tasks piled up in the status ‘implemented’ or ‘on staging’ more and more each day while scary few tasks got ‘done’. This is a clear symptom of our still creepy, manually, bottlenecked release process which on top of that depends on our overburdened IT (one argument why I’m a strong supporter of DevOps). Hopefully this will be another provocation for seriously tackling this topic together.

What I tried to tell

For me it was really impressive how the simple contraints of a Kanban workflow lead to immediate feedback about improvement potential and how simple you get a visual indicator for (even already known) problems.

Well, as you might know some time ago the Pope was visiting Germany – that was the reason for some big and atmospheric events where many Christians draw hope and inspiration from. Myself however was at the ALE2011 some weeks before and in reflection I noticed that there are some parallels between religion and agility.

I work in the agile diaspora. According to a free translation of the German Wikipedia article this is “a place where a special-minded people, who left their traditional home, live under completely different thinking ones”. And like a missionary I am trying to spread the true faith of agile here – what is anything but simple. In contrast it is reaming work, showing mostly small successes which nevertheless make proud. Sometimes it is hard not to loose faith or give up and move on. “He who fights with monsters should look to it that he himself does not become a monster. And when you gaze long into an abyss the abyss also gazes into you.”, as Nietzsche said in “Beyond Good and Evil“.

To overcome such valleys of doubt there is nothing more important than meeting like-minded people and hearing the consolatory words of the clerics of the agile church: the coaches, sitting in their Vatican Palace, philosophizing about the true interpretation of the agile writings and congratulating each other for new, deep insights and inspirations. They, who come into the faithless land, bringing the burning fire of agility with them, willing to inflame the hearts of mankind. And even if we, the ones from the stony fields, ask ourselfs “W.t.f. do I have from those cardinals of agile when I come back to my company – aside from their blessing?” it is so important to fuel up the energy, receive confirmation to be on the right way and get inspiration from conversations with many of the clerics – and more important: the laymen, struggling with the same problems like me.

So hear me, agile missionary out in the diaspora: search the community, visit local user groups, go to conferences, speak to people from other companies, read blogs, Twitter, LinkedIn. But don’t just stay alone and let withdraw your faith.

For me, the most important thing to notice is that the helpdesk people – and NOT the product owner – prioritize the issues to be solved in the time reserved for bug fixing during the sprint. For this, Kanban is an excellent approach.