Fight the power

And in my context, the power is time. Been a while since the last proper update, is it because my days are uneventful? On the contrary, it’s quite the opposite.

Met with Scania last week, had an interesting 2-hour session with a team there discussing MBSE together with two colleagues of mine. I can’t help myself to be impressed with their relentless focus on the customer. -In-every-context-. Of course one could argue that sometimes it gets too much, but I think it is in their consistency and endurance to keep that focus you’ll find the explanation to their edge. Anyhow the discussion was really pleasant, they have a lot of ideas and the people there like to twist and turn the arguments which make for a fruitful dialogue.

Have to comment on my SAAB assignment as well, passed the 6-month mark now and by then you are starting to get settled in. In the beginning I liked the assignment a lot, and I have to say that it only keeps getting better. Guess that’s easy though when you are working with great people, interesting technology, new challenges and opportunities almost daily, and all in an environment moving towards agile. For me it has been extra rewarding so far since it’s been a while since I got to work the full scope down to the smallest bit and byte, something that definitely improves my ability to work with the bigger picture.

Outside the scope of SAAB there’s a lot going on. Since 1st of July I’m standing in for a colleague in Gothenburg as Business Area Manager. We have great people working with architecture and MBSE and I try to help them channel all that knowledge. There are a lot of great ideas and with all those talented consultants it will be really interesting to see what we have achieved given some time. Next big check-point is our conference coming up soon. Let creativity flow.

Funny, when I read through the post I notice how positive it is… I guess when I stop and contemplate over “now” for a second I realize that life’s really good at the moment. Uppåt! Framåt!

Just text makes for a boring post… so why not a clip from Grandaddy. No matter how much money you have nothing beats a good idea, I love the simplicity of this video. It will be really interesting to see what the guy behind it come up with making a video for Tomas Halberstad.




Oh, and reading a book from Jim Coplien on Lean Architecture at the moment (will probably share some thoughts here later). He quoted someone (who I apparently forgot the name of). Think about it.
"Live simple, be complicated."

What is an agile architecture?

Agile is an adjective that mean something along the lines of "quick and well-coordinated in movement", how can we then couple that with architecture?

In my opinion we can’t. Agile architecture is confusing and sounds plain wrong, at least to me who rather think of stability and considered flexibility than quick and nimble.

I can agree that using the phrase “Agile architecture” sets a certain context which can give a reader or listener a notion of what is to be discussed but I still don’t like it. In a similar fashion I don’t like Lean architecture even though I think that the Lean values (the ones that differ from “agile”) fit better with architecture on many accounts. But what is a Lean architecture? Really?

I rather say just architecture. To me the field of software and systems architecture is constantly evolving and the truths I thought correct a couple of years ago are considered mouldy and obsolete today (or maybe I just understand a bigger picture now than back then). It’s important though to point out that what’s evolving is the way we approach architecture, how we work with it etc., whereas the technical aspects don’t evolve as fast; e.g. patterns is still an essential concept, domains as well.

So architecture is architecture but what about Lean and Agile?

Well, I would much rather phrase it along the lines of “Architecture for Lean/Agile organizations/development”. The technical tool-box of architecture doesn’t really differ if you are applying RUP, Scrum or grand scale waterfall, but how you approach it might (and probably will) differ.

I still think architecture is very important in order to reduce cost and make development, maintenance and destruction more efficient so to neglect it would be wrong in my world, but I do think we need to do it a bit differently to achieve better results.

 

• We need to include more people with different expertise in the beginning to envision where we are heading. 
• Someone can “own” the architecture as his/hers main concern but we should embrace that everyone contributes to the architecture. 
• Product management is recognized as a central piece of the puzzle to continuous success and architecture is very tightly coupled to PM.
• The architecture needs to be documented but we need to improve this area heavily (the old large system architecture descriptions won’t cut it). Documentation should preferably be in such form that it conveys the architecture automatically so reduce the textual descriptions to be the rationale that is needed to understand (and be to the point). Instead document architecture in e.g. code directly where possible, or as structure in an information platform etc. I.e. make the documentation part of the solution.

Architecture is good and well-needed but don’t confuse yourself that there is a hip new cool agile architecture out there.  I have.

 

Have.

The responsible designer

Some food for thought can be found here.

West side

Spent two days last week in Gothenburg with all the nice colleagues at our main office.

A lot of business development discussions involving our Vinnova projects, product management and software/system architecture for agile or lean organizations.

As usual it was great fun and a learning experience. Thanks all.

Tomas Sandén discussing model-based systems engineering

Powerpoint evening

Extrapolating a couple of presentations around Vehicle Software and Electronics Management and information modeling, IBC Euroforum is closing in pretty fast.

---

One interesting thing about my current assignment is the chance to work in an agile architecture team. I’ve been trying in previous assignments to influence teams in that direction (or Lean, but anyhow away from “Taylor”) without too much success unfortunately. Some might argue that Scrum isn’t the perfect fit for architecture teams but at least it is framework that brings a lot more positive momentum than the normal head-on document-centric waterfall.

Building an aircraft

Starting a new assignment today at exactly 1245 at SAAB (not the Spyker-kind but the flying-kind) and I’m really looking forward to it. It will be a nice change of pace compared to the more research-oriented Vinnova-projects I’ve been involved in recently.

Unfortunately I don’t think I will able to blog about basically anything I do over the coming months, being very secret and all… but since I will keep one foot going in both our architecture and MBSE group I’m sure there will be stuff to share and discuss.

Additionally you can look forward to some guest-blogging around both DCI and Lean from Mats and Gunilla. The pressure is on.

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…

Architecture for Lean and agile organizations

Yesterday I was in Gothenburg for a very long but productive meeting together with Peter^2. We started out time-boxing our day with the clear goal to get something useful down on paper. The focus was on Lean and agile (or actually just Scrum and not everything “agile”) and in what direction we would like to see architecture go. At the end of the day I think we have something good cooking now and the rest is pure make-up (well almost). It's about time I would say since we have discussed this for so long now.


It would be fun if we could get some “oomf” into the paper so we could send it to e.g ECSA 2010 (hence no details of what we actually talked about here).

We’ll see, anyway days like yesterday are one very good reason why KIT TM is a good place to be at. Thanks Peter & Peter.

Lean some more...

... if you want to know more about system architecture at Scania you can also visit IBC Euroforum in April where Staffan is one of the speakers...

Lean Software/System Architecture

Softhouse publish a neat little mag called Lean Magazine. In their most recent addition Staffan Persson from Scania describes how they apply architecture in a Lean culture. I’ve couldn’t agree more to Staffan’s words and I’ve tried in recent assignments to gently push towards this philosophy… in this respect I think Scania, from what I’ve seen in my assignments there, currently is the beacon in the sometimes hazy embedded industry in Sweden. Scania represents a very clear step away from the Tayloristic approach which definitely is appealing.

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.

Kanban

Kanban in roughly 2,34 minutes can be found here -->

And yes... I still think it is a good idea to use Kanban to visualize the work-flow in for instance an architecture team.

Early weekend

Slow week on the far side of the blog busy nevertheless. Modprod is closing in and the message in my talk is getting there…

Reviewed a presentation from a colleague earlier this week and found two topics extra interesting in his talk; the evolution of PD connected to the market-development and the “architecture” of agile.
Seen similar slides before but liked how these where packaged.
Maybe something I will get back to here after some further discussion.

Thinking/working/sweating a lot in the context of marketing during the start of this year, maybe I should just do what Jack does?




Well time to get packing for that Åre-trip, packing is best served together with Teddybears STHML.

Crank it up high cause "them drum machines ain't got no soul" (thanks for the tip Tomas).

/ Out.

Kanban & architecture

Just paused for a minute with a fresh cup of coffee and wandered off towards architecture in my mind.


Can Kanban be used by an architecture team? I tend to believe so even though I haven’t had a chance to prove the theory in practice (would be interesting though to hear anyone who has). Working with architecture has a very service-oriented side to it and tends to be somewhat interrupt driven. Additionally in large organizations it is easy to swamp the architecture team with work and as the stack in the inbox gets higher the focus and completion rate decline. Additionally other tasks, part of the normal process, are chunked in so big pieces that it is very easy to lose track of the target.

With Kanban you could get a tool to prioritize between the “service jobs” and “normal tasks”. Additionally you would have to create more tangible chunks of work which give you a sense of progress.

And if you still fail and are just drenched in work the Kanban-board would be a good visualization of just how much you and your team are trying to do… or maybe you are doing things you shouldn't?

Would be interesting to try at some point.

Architecture from the cabinet

Spent 30 minutes going through some old material to see what to keep and what not, found this jpg snapped from one of my architecture presentations… been a couple of weeks without talking so much about architecture, in some ways a couple of weeks too much.

It is interesting to follow the debate about architecture, the “to be or not to be”, commonly in conjunction with agile methods. For me architecture is one of the corner-stones for successful product development… but I guess it all boils down to the interpretation of architecture.

Monday

Sort of a Monday today. It felt like riding through a wet blanket to work this morning.

Guess the Monday feeling origins from the fact that I have a lot of interesting tasks at my table now and I have to juggle them around without losing too much focus. My main priority is the Vinnova project for automotive I’m involved in and Tuesday/Wednesday will be dedicated to a, hopefully, very interesting training session on the subject.

I also work a lot with architecture in a lean and agile context at the moment, an interesting subject that fans out and involve more than you would think. And no, not only product management which is the obvious direction to look… there’s also other implications and ideas. But since I made a promise to keep it a secret I will. For now.

Well just got an e-mail from a colleague of mine with a question regards to organizational structure and post-compile configuration files. Fun question and I think Vinnova and Architecture have to wait.

…and Maurice Jones-Drew really used his head when he stopped shy of the TD to run down the clock and deny Jets the opportunity to come back after a FG in the last play. Damn Jaguars. Damn smart players. It’s not about scoring in the moment; it’s at the right moment. Sob.

A day at the other office

I went to Gothenburg and the TM-HQ yesterday. First off 6 hours in the car with my co-workers Gunilla and Mats is always great, somehow we always seem to save the world during those rides (and Gunilla, don’t forget Flight of the Conchords). This trip also gave us time to go through our latest survey with regards to employee satisfaction and it seems that working with Technology Management is great fun.

As if we needed a survey to know that?

In Gothenburg we kicked off with a meeting discussing one of our business areas (focused on architecture). We made some exceptional break-troughs during that meeting. So exceptional I won’t discuss them here. Yet.
Now I just got to get down in writing what we said, fluttered about, scribbled on the board, shouted in exclamation. And so forth.

After our “office meeting + lunch” (which was as usual interesting and this time around also inspiring, at least to me) we continued working with the business areas in larger groups and then concluded the day with a session in our Obeya room. The Obeya room is a recent addition at our office and I like the idea, since we work a lot externally with Lean Product Development etc it makes sense to use fitting techniques for our internal “knowledge process” as well.

Full of energy today… guess it comes from meeting all the people yesterday.

So – Upwards. Onwards.


Flight of the Conchords - formerly New Zealand's fourth most popular guitar-based parody folk duo

Agile architecture

While waiting for Windows 7 to install I started to scribble some stuff on a piece of paper. One very long piece about MBSE which I will post in a bit and one shorter piece on agile architecture.

I simply started to make some bullets what agile architecture is to me.

- Much more collaboration between product managers and architects. Much much more. They should be like bread and butter.

- It is about setting an initial structure but maintain an everlasting mentorship/coaching role... without getting to cranky if the structure have to change along the way... simply because there might be a more fitting structure.

- It is about using models and other visual means to spread your ideas

- It is about creating patterns and other OTS-solutions that can be applied to common problems

- It is quite a lot about communication and providing a service

Basically it is all about using techniques that make you a good architect but take leverage in the agile philosophy.


And of course there are more down to earth implications such as how you would act in a Scrum team etc but I ran out of paper...

Do you have more bullets?

Is it really Agile vs. Architecture?

Just read this article at IDG.se. First off the article itself doesn't really say that much... what's the message that the journalist at IDG want to try to get across? People have different opinions?

Though after reading it I start to contemplate a bit... personally I don't see a conflict between the ideas conveyed through the agile manifesto and the purpose of the "discipline" we call software and/or system architecture. I can understand that there are probably individuals that perceive themselves as part of either "community" and that their "corner" is better in some way...

But that says much more about these individuals than anything else.

I also agree that architects can be rigid and inflexible, that they can be "waterfally" etc... but that that says more about their performance and the environment they operate in. I wouldn't call them good architects... or maybe they are but got their hands tied down by the major cooperation process X.

The quote from the Microsoft guy is peculiar (if he really said it, you never know with an online-paper) and I have heard it before and didn't agree to it then either... there is nothing in the agile manifesto stating anything about architecture more than the following (from the subsection “12 principles for agile software”) "The best architectures, requirements, and designs emerge from self-organizing teams." Ok, maybe we should take "emerge" literally but personally I don't.

The notion that "agile" mean that architecture should be built bottom-up is just one example of TGW when agile becomes Agile and people start to attach methods/processes/etc stating that this is the way to do it... Maybe bottom-up is ok for some scenarios but I can guarantee that I can find a scenario where initial envisioning of structure etc is absolutely a must. The point with agile from my perspective is that we should go with whatever fits our needs the best. Coming from the embedded world and large distributed systems I can’t really see a bottom-up approach as appropriate… that said the extreme top-heavy top-down approach isn’t good either.

Though I do like that the article concludes that agile and architecture should come together, for me it already is.

Travel as I wait

Gunilla Hammarberg, not only my boss but also a rock-solid engineer, said something I'll steal: "Architecture is an activity rather than an artifact". Why is this so obvious but still not?

For me it is clear that this is the correct mental picture but still it is not obvious that this is how it works.

When we use processes that says something like "by gate X you should deliver document Y" people tend to focus on getting that document done, or? Especially since in many companies we build up a very large organization to check that document Y actually was delivered by gate X. If the people chasing the document is stronger than the persons behind them it don't take long until the authors are bullied into a document factory. When it comes to architecture I think it takes strong personalities to see through this and to get acceptance in their respective organization to shift focus.

Don't get me wrong, I don't say stop writing that System Architecture Description but shift focus. Spend 20% on the artifact and 80% on activity instead of the other way around.

When looking at it from the Lean angle architecture as an activity becomes even more clear. The quite common artifact-driven organization is a easy example of a "push" system and even though a lot of SAD:s are good documents it doesn't take long to identify a lot of Mura, Muri & Muda - or waste.

@"Travel as I wait": Since I know that a Philosophy-student (click and listen, he's not only philosophical but also an excellent musician) is reading this I might as well educate him a bit:
Lean Software Development in brief(s)