Coupling and cohesion

An old concept but still going strong, the important cracks in the MBSE wall to fix is what’s in between; in between the different domains, disciplines, methods and ideas.

To the finish line

Actually worked some during both Christmas and Boxing Day, helping out a friend of mine I had to “re-learn” how to setup an Apache-server, use MySQL with PHP and how to make it all run smoothly together with Netbeans. After getting a friendly tip pointing towards XAMPP it all became a lot easier and some nifty “modeling” on a piece of paper later I took off coding. I’m actually a bit surprised with what I achieved in only two days… which is good since I don’t have a surplus of hours stacked away, but I promised my help and that’s that.

But today it’s Monday again and normal work-day. Been digging through a lot of reading material with regards to SysML and MARTE and the combination of the two without getting a real wow-experience… maybe it is experience, maybe it is cynicism… I don’t know. Well I need to stay positive anyhow, to give it a proper chance.

Tiny can make big

Even though annoying, the small problems sometimes help you find the bigger issues. The last week has been a plethora of small breadcrumb sized mishaps, now the loaf has been found and the satisfaction can’t be denied.

March in December

Later this year I will do a short guest appearance, again, in the Vinnova-funded VCC project March/DFEA2020 so today I’m doing a bit of reading, catching up if you will. One of my recurring concerns in the area of MBSE is that there’s really not that much to catch up to. It still seems as if the prevailing ideas are the top-down approach in some form where either method has their solution to achieve traceability and a “Russian doll” situation.

I’m more interested in what aspects of modeling and systems engineering that will benefit your organization and constantly improve performance. To me most of the large MBSE initiatives/methods are very bulky and impose a clear and present risk of putting a lid on engineering and innovation.

Some random questions I find interesting:

How do you move focus from verification to validation? The ability to do trial and error, short prototyping loops etc. are vital, what do you need to support this?

How do you push “decision power” closer to the problem? With an over-weight top-down approach this is impossible. How about creating a more loosely coupled architecture based on patterns and some well-placed poles in the ground designed to keep the solution within acceptable boundaries compared to important attributes?

If you product is multi-faceted you will be using different tools and languages to describe it (don’t try to dig with a fork if you have spoon), how can you provide aid to minimize hand-offs, or at least confusion in hand-offs? Instead of attacking traceability you might need to start in a different end, to really understand the information need and information structure in your organization.

If you are implementing parts of the system in-house you want to give the SW-department the best possible pre-requisites in order to do their job, how can we do the same for those parts developed by suppliers? Can models help us increase transparency where needed in our supplier communication?

Models instead of documents push towards construction and engineering, if our organization has started to lose touch with those disciplines we are in danger of applying Models Based Systems Drawing instead. How can we mitigate that imminent risk?

And why is it that it is so rare to find the notion of a lean or agile mindset in conjunction with MBSE? If we want to run our implementation according to agile principles we need to understand the implications and changes in approach needed when it comes to architecture, integration, systems engineering etc.

Sometimes you miss the strangest...

... last week it was Canoe.

Of all things?

Wireshark in all it's glory...

This. That.

Had a busy day today, the board meeting at the University went well and the speaker-list for Modprod 2011 is getting really close to release. From that straight back to SAAB and host a section in a training program. It’s always difficult to talk about a large subject in a very short slot but at least they know who to contact now. And then back to business which was semi-successful, but there’s always a tomorrow.


It’s interesting to observe how different personalities tackle a large scale development project. Some projects can be like inventing a new sport while playing it, without a referee. Some people go full throttle and play and try to learn as they go along, realize that without a rule-book short-cuts and quick uninformed decisions can sometimes be necessary to achieve the goal and win. Some people just sit on the ground and refuse to play until someone shows them all rules, nuances and a referee. Of course there’s a grey area in between all that black and white but sometimes I don’t really understand the person tapping out before the game even start.

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.

Sands of time

Been difficult to find time to blog during the last couple of months, maybe it has something to do with priorities.


Last week we arranged an interesting seminar on lean and agile here in Linköping, Göteborg is still to come so go ahead and sign up on www.knowit.se/lean and be sure to ask some tricky questions.

So far the assignment at SAAB Aeronautics has been a really interesting journey. I’ve gained a lot of insight with regards to Scrum for larger industrial projects, and I’ve gained some confirmations on theories I’ve been juggling with before. Having worked with organizations and “processes” all over the scale I have to say that so far Scrum has proven, at least, to be the most fun. And when it comes to building teams and creating momentum for delivery it hasn’t really disappointed yet. Or maybe it’s because there are a lot of quite awesome engineers at SAAB?

On Wednesday it’s time for another board meeting with Modprod, http://www.modprod.liu.se/ , at Linköping University. February and conference time is closing in pretty fast so it’s time to dig in and execute all actions to bring it home.

In January we are turning a page here at Know IT Technology Management in Linköping. It will be really interesting to see how 2011 pans out, after the board of directors meeting we had together with the Göteborg and Stockholm office last week I feel a bit rejuvenated though, a slice of energy was well-needed during this exceptionally gray November.

The power is fought and the pendulum swings again

Few posts back I embedded the Grandaddy video made by Stewart Smith. The video he directed for Tomas Halberstad is now released and Mr Smith continues to be a genius of simplicity.... and Tomas makes great music.

Triad of complexity

I really like Gunillas discussion around complexity, it is really simple but somehow it just gives me a new perspective.

Next time you are discussing a complex issue, think about what's complex about it...

Is is functional, dynamic or computational complexity?

Often you simplify by just stating it is complex ending up trying to solve a e.g. functionally complex issue by using a "dynamic approach"... or actually the most common case is that you have a complex dynamic problem that gets even worse when you apply a tool designed for functional issues.

The vampire's gaze

Why is it that models seems to entice us engineers to use a means for simplification and just make things more complicated? Too often we forget the most important part of modelling - the Why! Instead we get caught up in discussions such as:
- Tools
- Model structure
- More tools!
- Process and roles

... and in the end we seem to crank as much information we can into one big model and hope for the "one size fits all" wonder.

But really we should just repeat why why why and try to use models to fit that purpose.

Say you work with the electrical system of a car, how would you apply modelling to:
- Vizualise dependencies between components?
- Analyze power consumption?
- Structure the software of your engine controller?

Would you use the same model? Would you use the same modelling language and technique? Would you consider a table/matrix to be a model? It all depends on the why.

Being interested in software/system architecture I seem to be forgetting the why a lot myself, or at least in the past. The most common pitfall I've seen in different industries is architects becoming "trigger happy" in models and get caught up in details that really shouldn't be their concern.

Don't get me wrong and think that I blame the models, I do believe MBSE is necessary in order to keep a competitive edge but we need to be a bit less amazed with the beautiful "pictures" we draw and a bit more focused on... Why.

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."

Lost in space

... or more accurately Lost in Namespace.

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

New challenge...

... been looking for one, maybe this will do?

SDC

Abstraction is evil

Been a while but attended a very interested seminar last week featuring Jim Coplien (author of the book “Lean Architecture: for Agile Software Development”, among other things) titled “Modern Domain Analysis for Agile System Development”.

I’m not going to try to recap exactly everything Jim said, you’d be better served to listen to him the next time he speak at a venue close to you, but I will dish out some snippets. I don't necessarily agree to everything Jim said but he made some really good points and made me think and reflect which is what I want out of a seminar. As he pointed out this topic is much easier if you are building a web-based application than if you are working with embedded systems, but hey the world is complex. Tough luck.

 

• Abstraction is evil but compression is good. In Jim’s view all abstraction makes information disappear and we can’t afford to loose information.
• Architecture is the essence of structure, i.e. the form.
• Agile architecture is about making the hard decisions early to make the easy decisions easier later. To defer decisions to “the latest responsible moment” is stupid and simply wrong.
• Agile architecture should provide a stable ground, not necessarily a static ground. It’s about knowing what changes we can ignore.
• Software architects that don’t write code aren’t software architects. Everyone that writes code is part architect. The whole team should be included doing the architecture; the tester, domain experts, system engineers and programmers.
• A good architecture should reduce rework and inconsistency.
• It’s not about no documentation but the documentation should be to the point, only include what matters. The rest of the architecture should be communicated through the code, e.g. abstract base classes.
• Architecture follows the organization (Conway’s law) and the social connections in the organization (rather than the org. chart, and organization follows location, market etc). Other influences to the architecture is the end-user’s mental model, the shear layers with regards to what the system does and what the system is, and finally the domains as long-term stable concepts.
• Partition your system to domains using intuition and history. Analyze your domains, analyze commonality. Find your parameters of variation. Use patterns but beware GOF isn’t patterns.
• DSLs fail.
• Scrum is very good for systems with end-user interaction and GUI, Scrum is very hard for embedded systems…. basically you aren’t doing Scrum.
• An incremental approach to architecture leads to poor structure in the long term, you should do it first and then change it when needed.
• Agile only focus on the revenue but forgets the cost, architecture is a means to reduce cost.  
• Scrum is waterfall but that doesn't mean it is bad.
• You work best with “Architecture” influenced by both Scrum and Lean.
• Scrum is not Lean.

Last but not least. Jim talked around the picture below from an organizational stand point. The picture shows a map of the world from a New Yorkers point of view:

(high-res can be found here)

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.

Leaving the trees behind

Off I go to Gothenburg and the west coast tomorrow; it’s time to talk at the IBC Euroforum conference “Electronics in vehicles”. If anything it will at least be nice to see some old colleagues from Volvo and meet my current Know IT ones.


Besides the very nice assignment at SAAB there’s currently a lot of Know IT business development going on, particularly I’m keeping myself occupied with some ideas around agile development as well as technology management for less mature (in terms of electronics and software) organizations. The space and time for these kinds of discussions and concept evolution is one of things I really like about KIT TM. Oh and not to forget the thread around MDA.

As far as Android goes the time for playing around with Eclipse and the SDK is rather rare but I have been able to play a bit reading sensor data. Besides the serious discussions around apps that I have with a Gbg-buddy of mine I’m keen to try something around augmented reality (after first talking a bit with Torkel and then checking out some demos on youtube).

AA

Jim Coplien is coming to Linköping in May talking about Agile Architecture, a really interesting booking made by the good people at Responsive. Read more here.

Serious Android

Got a nice e-mail from one of my good friends back in Gothenburg today, he had some interesting and serious suggestions for Android apps (that he’s planning to realize on iPhone). We’ll see where this ends.

Next week it’s finally time for IBC. Been iterating the presentation for a while now and starting to go around in circles a bit, the final pieces will fall into place while talking I’m sure.

The last couple of days I’ve been getting acquainted with Q as well. Maybe not the most pleasant experience but in the end it gets the job done. Or at least it might. The interesting part though is to see if we can auto-generate necessary input straight from a SysML model.

Additionally I had a brief e-mail discussion with a colleague in Gothenburg about xtUML, code generation and model verification. Good to see that xtUML is getting some attention around the block; I definitely think there are some goodies to collect there. Hopefully I’ll have a chance to continue that dialogue this week since he had some follow-up questions on CM.

Well, time to open Eclipse.

I'm an android

Always liked android... ever since the paranoid version.

And now my phone is an android as well so being an engineer and all I have to try and fiddle with the full potential of my phone.

So I've installed the Android SDK ontop of my Eclipse. All I need is something fun to do (something else than Hello World). But what I really would like though is to see if I could round-trip (model-code-model) using e.g. Papyrus. Been discussing round-tripping on and off at work and would be kind of interesting to see what you can do by just using open-source.

... and it is a good time as any to practice my, currently, mediocre programming skills...

Suggestions for an Android app? Current front-runner in the app-race is the "find your closest Systembolag app" by popular demand at the fika-break.

Volvo

I haven’t really had time to think about the blog for a while but the world apparently haven’t stopped moving even so ;)


The purchase of Volvo Car Corporation is now a fact. Having worked at, and for, Volvo for quite some years I’ve followed the events with great interest. I know that the same people that have had issues with Ford will now have issues with Geely and think back at Ford as the “good old times”, that is inevitable but also quite natural since it’s a typical pessimistic way of life.

If I had still worked at Volvo I would think the separation from Ford or Europe would be sad… mostly because I enjoyed working with the people in Cologne (as the separation from Jaguar was sad since a lot of good guys worked there as well)… and in some ways FOE pushed VCC to excel and we learned a lot working together.

I also think that the people at VCC really learned how to work in an international environment something that of course will benefit them with a Chinese owner as well.

No one knows how the new owners really think, but I tend to have an optimistic view so maybe this is Volvo catching a break; a chance to become an even better company. Hopefully they have learned a lesson with regards to rigorous processes, large corporate frameworks and similar and choose to approach development in the future with a more lean approach.

If Li Shufu really means what he says then Volvo’s fate is in her own hands.

To MDA or not to MDA

Interesting mail-discussion going on with some colleagues at the moment… can you e.g. adhere to MDA using Simulink or, being an OMG initiative and all, is UML (or UML-like modeling-languages) implied. Personally I don’t think that MDA contains any prescriptive view upon which modeling language to use… but some fit the purpose better than others.


What do you think?

F18 Super Hornet

... and maybe it is time to change my picture in the heading...

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.

Experience Lean

Our seminar Lean experience last week was a success. Personally I think we managed to get a perfect mix of speakers; academia, real-life example with a lot of boom to it and a more reflective approach based on very long experience.


You can find the presentations on our homepage.

It’s fun to put together events like these, based on the amount of participant I really think and hope we’ll do it soon again.

Data Context Interaction

My colleague Mats have written a piece on DCI. A subject I have yet to understand ;)


Click here to get enlightened.

A hard days night

New assignment always means busy times so the blog suffer a bit. Really nice assignment though so I’ll live with that. A lot of things going on at the same time; just the way I like it.


Tomorrow it’s time for our Lean seminar to finalize the mini-tour around Sweden with a stop here in Linköping. I’ve been working quite a bit with the seminar the past months so it will be great to see the result of all efforts. From what I’ve heard the Gothenburg-session was a success.

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.

Someone did think about it...

I had a short chat with my friend Tomas, who is majoring in philosophy, today. Really appreciate the discussions with him since he is pure from any R&D-baggage… an untainted soul.

Basically he had some remarks on the two rationalization options in the previous post (one could argue that those two lines are generalizations of Lean and agile) and basically he questioned why there wasn’t a third line stating

• Rationalization through sense and reason – Rational rationalization

Well maybe it is a general and obvious statement but definitely a line worth discussing because sometimes we tend to focus too much on ready-made plans, available tool-boxes and methods… and somewhere down the line forget sense and reason.

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…

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.

Kanban myself

We've started to use a Kanban-board at the office... we'll see where it takes us. The fuzzy picture is quite intentional... maybe there are secrets on the board, who knows?

Modprod 2010

So Modprod 2010 has come to an end and as last year I enjoyed the conference. Besides the obvious networking, highlights for me were the Requirements Modeling session with Kristian and the keynote by Hilding on Modellica for embedded systems. With regards to “our” performance I’ve only heard positive feeback on Gunilla’s tutorial “MBSE in a Lean context” and I think my 20-minute talk on Information Platforms was ok but next time I will put more emphasis on “what” rather than “why”.
During Kristian’s session we had a discussion around the difference between abstraction and design… arguably sometimes obvious but still he drew a quick example serving as a good mental reminder.

Regardless how obvious it is what’s abstraction and what’s design above I think mistakes are common in practice.

Modprod Day 1

... is coming to an end.

Interesting day and the tutorial on requirements modeling was a positive suprise... might come back to some details when I'm back on Thursday.

http://www.modprod.liu.se/

Lean experience

Our seminary-series Lean Experience is now announced, head over to our homepage for more information and registration.

http://www.knowit.se/lean

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.

A perspective from games

Found this blog post quite interesting because of the immediate visual perspective it gives. Sometimes one tends to forget just how rapid the development over the last decades has been and that’s not only in terms of computer games.


Additionally the irony in calling the first Wolfenstein game 3D is simply brilliant.

Diverse patterns

Yesterday was spent with two colleagues from our Gothenburg office at SAAB here in Linköping. Together with SAAB we at Know IT are one of the partners in a Vinnova project focused on electrical architecture (more information about our Vinnova commitments will be posted on our homepage in due time). It was a very interesting day with a lot of discussions around functional system safety and patterns. I think above all what struck me was the very competent first impression the two SAAB-employees made, they really knew their way around the block with regards to embedded development and safety. Inspiring!

Yesterday's patterns concerned safety; today the patterns are focused on separation of concern. I’m trying to compile a few but meaningful slides about MDA in order to help a co-worker. MDA for me is more than just transforming models to code; I tend to give the word a somewhat bigger scope than that. For me MDA, done correctly, can be used to bring leverage not only to the product itself but also how you build your organization. Of course if you are a software company MDA can facilitate HW-independent development and re-usable code generation but from my perspective you don’t have to have a programming department in order to gain benefits from an MDA sense of mind.

The basic MDA pattern. The x can be both S and I depending on amount of layers.

[P:Platform, M:Model, S: Specific, I:Independent]

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.

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.

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.

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.

Agile today

Here's a link for anyone interested in agile development.

Analysis to design

Currently involved in a lot of more business related tasks but I get to squeeze in some technical thoughts in between as well.


One that I’m exploring a bit is how xtUML and “MDA” ideas could be used to create separation of concern between very abstract analysis (or maybe “architecture” if you like) models and design models. Of course it is not so much the separation of concern I’m after as the possibility to do model to model transformation, but “soc” feels like a necessary means to achieve just that ;)

In my head, maybe I’ve got it wrong, this is initially not so difficult to achieve but when you put it in context it suddenly become a tad more problematic. Especially since it is not the pyramid-structure of transformation I’m after (you know, the “Babushka” structure…) but something a bit more intelligent where the transformation would handle e.g. cases where you go to different levels of abstraction in your analysis (because different problems require more or less details to analyze), where you could apply different patterns to solve various problems etc etc

One question though, and slightly important too, is if there would be a business case to do it this way. Another way to do it would be to kick-start with analysis models and let them evolve into design models over time (this could be a beneficial option if you don’t connect any value to the analysis model themselves and want to be able to re-use them etc).

Anyone with thoughts/ideas?

Well back to more “management” tasks.

Aeroplanes

Lot of things going on today but with the huge game coming up this weekend I have to do a "non-work" post.

Rex Ryan has a lot in common with the old Swedish soccer coach Tommy Söderberg, besides the look they both use management by “positive attitude” to build confidence for the underdog.


Hopefully it will pay off against the charging bolts on Sunday.
J E T S Jets Jets Jets

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.

Automotive transformation

Here you can find a long but interesting article on Automotive (from the Wall Street Journal) and an industry going through a revolution.

"The most remarkable aspect of last year's bailouts and bankruptcies is how auto-industry neophytes cut through craziness that had existed for decades. GM didn't know its cash balance within half a billion dollars on any given day. "

"After careening from one disastrous decision to another between 1999 and 2006, Ford had come to grips with its fundamental need to change. The company changed CEOs and is now shedding debt, dealers and brands without federal funding. Ford isn't home free, but its progress provides proof that GM and Chrysler could have avoided bankruptcy too with better leadership, and the willingness to act decisively before it was too late. "

No progress

So far it has been a bit frustrating today, I’ve got several important issues on my table but no real progress to report of.

Reading through the papers and the circus around SAAB Automobile continues, personally I hope that it somehow works out for the best for the Trollhättan people but honestly the business case for long term survival doesn’t really seem to be there (at least not what one can depict from reading public material). Even so I find it a bit irritating reading through some blogs from prominent persons where they give themselves credit for “predicting” difficulties for SAAB a year ago… I mean, did anyone predict anything else? If you are one small non-profitable piece of a huge non-profitable organization the math is quite simple; SAAB is not the only thing at stake here. That Spyker or Genii would able to procure SAAB through their latest bid has great odds obviously…

…but great odds doesn’t mean impossible.

Well, time to get back to some marketing material.

Possibilities

New year but still in need of new people, hope you haven’t missed that we at Know IT Technology Management are recruiting in Linköping, Stockholm & Gothenburg.

Additionally I've got a very interesting meeting scheduled for tomorrow discussing seminars during the spring. I’ve got one up my sleeve that hopefully can see the light of day.

Life in technicolor

Been a lot of powerpoint management today... and not sure if I am to pleased with the result. What I really should do is to go back to the white board and practice the talk without any aid but a pen... whatever I scribble down on the board is what I should put in the presentation.


But then again, when the powerpoint is supposed to be left behind it needs to be able to tell a story on its own... ah well, I’ve sent the embryo on a peer-review and I think a gentle push in the right, or any, direction will be helpful.

IBC Conference

Another conference confirmed. In April I will talk at the “Electronics in Automotive” conference hosted by IBC Euroforum in Gothenburg. Maybe I’ll see you there?