Think Talk

A while back I bounced a couple of mails back and forth with Tomas Sandén from our Göteborg office. I was planning to submit the outcome to a conference; I still might but not sure when.


Anyhow, I thought I’d share some of the key questions or statements we formulated. I could feed you with how I would answer them and build up a speech, but it is more interesting if you contemplate yourself. If you feel the urge to discuss them there’s always the comment box.

So the talk was going to be around team organization and improving “speed” in companies developing some type of product(s), or “industrial scrum” as I sometimes refer to it when I’m sloppy (which is a somewhat bad term since scrum per se doesn’t hold the complete answer and since industrial can give you a very incorrect mental picture).

Tomas summed up the bullets that we were sort of coming back to all the time, so here are those questions for you:

• Can you regard scrum as an organizational pattern for teams, and as such is it strong?
• Can you gain focus and drive in a large PD-organization by relentlessly shortening the feedback-loops and lead-times?
• How do you balance the focus on external customer value with the need to appreciate internal ditto?
• Is the transparency provided by Scrum enough when the development is distributed in several teams and over a longer period in time?
• How do you balance product management - development - pre-development with minimized over-head?
• Should the focus really be to have better control mechanism, development methods etc. than your competitors, or should it be to be able to learn faster?
• Which have precedence and why; Quality or velocity?

 That will have to be enough for today.

Scrum Scrum Scrum

Scrum can be easy. Scrum can be hard. Scrum can be perfect. Scrum can be so wrong. Scrum can change everything. Scrum can change nothing.

Is it because of Scrum or the way we use it?

Is it just the pessimist stating that Scrum doesn’t work, or doesn’t add any value? Is there any truth to it? Is there truth to the optimist stating that Scrum revolutionized “our” business improving our performance with X percent? Was it because of Scrum or something else?

Personally I think Scrum is one of, or perhaps “the”, best model for team-work out there at the moment. But that’s also it.

I’ve worked for small organizations where Scrum actually might not be needed; it all depends on mindset of the people working together. But I can also see how it would have helped us become more efficient and focused on doing what counts.

For larger organizations though I think that Scrum as the team framework makes, almost, immediate sense. I’ve seen plenty of teams destructively working on unimportant tasks just to generate “heat”. To be stressed out for deliveries even though it is unclear what to deliver and why. To be bogged down by tasks from other teams without the quantity of extra work ever being visible. To be part of a team but completely unaware of what the other guys and girls are filling their days with. What they are actually filling their days with.

But!

To use Scrum in a larger organization is far different from adopting it in the little “SW-shop” with 10 or so developers. During Scrum trainings and seminars I’ve been getting answers implying that as long as you stick to SCRUM you are doing the right thing and that Scrum will point out where your problems are; irrespective if you are 100 or 10 people.

The problem is though that many of these problems can’t be solved by following the rationale of Scrum. Because for large organizations the team-work aspect makes sense but other straight lines in Scrum might need some bending. Or you will at least need to add things to deal with issues you have simply because you are a large amount of people with a lot of interfaces.

Scrum doesn’t have roles (besides the golden 3) and traditionalist state that everyone in the team should able to do any task… is that really practical, cost-efficient, or even possible? How do you put together your teams with this in mind?

Scrum appraises the retrospective but does that really mean you are working towards constant improvement? Does it really?

How do you Scrum when your organization are both assigned with product development and product maintenance? Can you time-box maintenance?

How do you fit testing into it all? Unit-testing sure, how about integration test?

How do you deal with geographical spread?

What do you do if the DoD depend on other teams?

How do you deal with extensive documentation that can be required due to legal or safety aspects?

How long should a sprint be when our cycle-times are long? To short and we add too much overhead, too long and we aren’t Scrumming anymore. Or?

There are a lot of questions around this that I find interesting, for some I think I have the (or at least one) answer and for some I’m still doing some soul-searching.

Something to think about...

A quick glimpse of what I’m currently working with, taken from a Peter & Peter meeting minute:

• Rationalization through quality – the law
• Rationalization through adaption – the team

 Gives you something to think about, doesn't it?

Puzzling

Slow week blog-wise but a lot of activity going on. Besides putting all the pieces of the puzzle together before diving into my new assignment I’ve managed to cram in some work on both xtUML and agile architecture.


So here I am listening to Seven Nation Army and writing an RUP-inspired explanation to how architecture and “agile” can connect. As a piece of this process a comparison of Lean and agile make sense… however when reading articles around the web things makes less and less sense… seems as the parties on either side of the imaginary fence try to advocate the opposite’s similarities where beneficial…

Or agile is the wrong word, the current focus in mind is Scrum.

An interesting observation is that the architecture mindset that I have fit quite well with Lean philosophies but when discussing it in terms of Scrum it is hard not to make patches and adaptations to the frame-work…

Random (s)crums

Some random “things” that I will take away from the CSM-course:

If you need a lot of system design you should still parallelize design and implementation (i.e. do it within the sprint) but it would be wise to add a Sprint Zero focusing on system design alone. This sprint will most probably be a little bit longer than normal sprints (depending on your system).

I will probably take a look at the book Software by numbers.

Ok I’ll cave; using modeling-terminology Scrum can be seen, roughly, as an instance of “Lean”. At least most of the basic principles, or values, are the same.

The Spec/Developer game that we played at the training should be played in every organization… the quick lessons learnt from that one are so easily neglected on an everyday basis.

When e.g. building cars or similar products there are a very strong focus on time, technology and cost, why is value repeatedly left out of that equation? Ok this one is not from the training itself but in Scrum the focus is on value and if anything you should, when prioritizing, look for at least MMF, Minimum Marketable Feature.

I should revisit the agile architecture work together with Peter and Peter. We are on the right track there and architecture is one of the difficult questions when talking Scrum. The answer at this course was that “architecture and infrastructure are highly prioritized non-functional requirements”.

Scrum in large organizations is difficult. Scrum in large organizations developing embedded products is even more difficult. But then again it is difficult using waterfall as well.

Tick tick

Just finalized the CSM-training by completing the online certification test and thankfully I passed... piuh. Ok, currently everyone pass since they are tuning the tests but you never know... anyhow I think my score would have been enough either or; not the most difficult of exams.

Quote of the day... yesterday...

Here’s one of the more memorable quotes from the CSM-training yesterday (as a reply to a lot of tedious questions).

"Just because we use Scrum it doesn't mean we should stop thinking"

I'll try to summarize said notebook tomorrow and see if I have anything insightful to say after a, I must say, quite good training course.

CSM

Two days of backlogs, sprints and burn-down charts coming up, after that I'll probably be a little bit wiser and a certificate richer. I took a Scrum-course back in 2008 and it was really good, hopefully this one will be interesting too even though I guess I won't really learn anything new. However if there’s a good mix of people the discussions around the training-subject can sometimes be way more interesting than the actual material itself.

Wednesday evening we’ll know.

Scrum and Kanban

Here’s just a quick link to a paper written by Henrik Kniberg at Crisp… hm misspelled it Crips at first, guess they are not affiliated.

Scrum vs Kanban.

It is an easy-to-read paper which gives a good introduction to both Scrum and Kanban.

I’ve always liked the simple idea behind Kanban… but Kanban Jedi can be one of the most ridiculous titles invented and just give me a bitter after-taste of “let’s invent a title we can sell”. It’s almost as frustrating as reading headlines like “Kanban, the new Scrum”. Titles and phrases like these just diminish what comes next since they take away all credibility. Almost.

Henrik K also wrote the well-known and good paper XP from the trenches.

Waterfall, Iterative, Scrum and Lean

I've seen summaries or quick-guides like this around the Internet...

I don't agree with this picture. Do you?

An interesting quote

I don't know how I ended up there yesterday, on some random guy's Twitter page... so I can't provide a link to it...

But anyhow he, the random guy, wrote this:

"SCRUM brings coordination of action, which is critical. Software architecture brings coordination of intent and insights."

Maybe not the most shocking or difficult line to come up with but hey he wrote it and I didn't... I kind of wished I did though 'cause I like it.

So if you look at it from that perspective how do you coordinate intent and insight? Maybe we should embrace that there is more to it than producing documents, excel sheets and UML-models? That there is a lot more to "architecture" than the technical aspects that we somehow like to indulge a little bit too much in?

The first thing I would start with I would steal/borrow/use from Scrum and the agile "world" where one common theme is the importance of Product Management. Step one for "Architecture" would be to reconnect (or strenghten the relationship) with Product Management in order to increase the insight in both ends.

Step 1 from a bigger perspective would probably be to look at Product Management directly so that "architecture" (and everything else) has something functional to reconnect to...