Mitt tidigare inlägg här (november) handlade om Användningsfallens framtid i ett mycket bredare spektrum av branscher än mjukvara, och om interaktivitet som nyckelbegrepp i sammanhanget, särskilt samspelet produkt – omgivning

- från Telecom Valley i öster till ”bilbältet” i väster.

One of the more important concepts of agile is that there is no one size fits all solution. For this reason I try not to use the term "agile methods" or "process" instead I try to think of the different options available as tools.

In fact, Scrum specifically makes a choice to refer to itself as a framework and not a process. One definition of a framework is "A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality". This is an important distinction, and one I feel many people fail to make. In my mind, agile methods are nothing more then a collection I tools that we can use to get the job done.

With this in mind I think it's important we are always trying to expand our toolkit in order to find the right fit for the situations we are in. I don't know of many successful Scrum implementations that don't use at least some practices from Extreme Programming. Likewise, I often encourage people to take artifacts such as backlogs, and roles such as product owners when using Kanban as a tool in their processes.

So, what I am trying to advocate with this posting is if you are a "Scrum person" take some time to learn about other topics like "the ten commandments of continues improvement". If you are in to Extreme Programming have a look if Kanban practices like work in progress limits might have something to offer you.

"When the only tool you have is a hammer you tend to see every problem as a nail."
Abraham Maslow

So please, add more tools to your toolbox then just a hammer.

Find more tools at Göteborgs next agile conference:
www.brewingagile.org

Time and time again I see teams making the same mistakes when attempting their agile transformation. Since one of the most important ideas in agile methods is visibility, I wanted to make some of these visible in the hopes of creating change. This is by no means an exhaustive list, just three I see a lot.

1) Non-experienced "coaches"

Let me be absolutely clear on what I mean here, I think that creating coaches, scrum master and the like from within you organisation is not only advisable, but vital for long term success. However, there are some pitfalls with this in the early days.

Transforming to an agile way of working is much more about a change in mindset then it is about process and tools, it's written right there in the agile manifesto, but changing your way of thinking is extremely hard. So, you have someone trying to coach the organisation on change, when they have not yet had the opportunity to make the change themselves. And it's a  lot harder to sell a product you don't use yourself. This often results in the teams and organisations not only having some strange ideas about what agile is, but losing confidence in it because the person who is driving it is still learning themselves. This person needs the time to really "get it" before they can help others do so.

I am not criticizing the people who are just starting out, they will get there eventually and we need their passion to succeed, but I was there myself once and I know the difference experience makes.

All that being said, be cautious if you are hiring this kind of support from outside, there are a lot of people who sell themselves as agile coaches, but have not really "gotten it" yet.

2) Transforming to agile with a traditional approach

Agile emphasises an iterative approach to things, but time and time again people try to become agile overnight.

It is impossible to fix all your problems at once, treat your "agile development" the same way we treat "development in agile". Focus on the most important things first, your biggest bottlenecks, and make some progress on them before you focus on other things. Use your retrospectives as a tool for this, take away one or two solid action points from your retrospective instead of a list of 15-20 things to improve. Fixing everything is impossible, fixing one thing is easy! Well, easier...

A lot of teams create backlogs for their improvement the same way we create backlogs for a products improvement, this can be a useful tool!

3) Hand-offs to testers

The idea with a cross functional team is that we have everyone we need in the team to take something from a request for a feature or product to the market in order to start making money from it, or "from concept to cash" as it's called. But early teams often take things "from concept to testing".

The reasons they do this are obvious, testing takes a long time, and if quality is poor the results of that testing are often unpredictable. But, by doing that we are trying to hide the problem outside the iteration instead of fixing it. The result is what is called "iteration avalanche".

The team "finishes" the iteration and hands off to testing.
Testing finds bugs, but the team has started the next iteration.
So, those bugs have to wait until the next iteration.
At which point the team "fixes" the issues and hands to testing again.
Then the whole cycle begins again.

Nothing is ever done in this approach, the team has to take back stories over and over again, and an adversarial relationship develops between testing and development. If testing is part of the iteration we are forced to solve these issues instead of hide them.

Testing is too slow? We need automation to make it happen faster.

Testing finds too many issues? We need to increase quality early to prevent this, test driven development  being the most popular approach to this, but not the only one.

As I said earlier, these are only some common mistakes I see, but if I can help even one team avoid one of these things, I will consider this post a success!

Jeffery Campbell

Microsofts har nyligen släppt SharePoint 2013, den 5:e versionen av företagets genom tiderna mest framgångsrika server-produkt. Plattformen kan användas i princip till allt och trycket från marknaden efter duktiga utvecklare och administratörer som kan SharePoint är enormt.

Att utveckla anpassade funktioner har varit komplicerat och installationer av dessa har tagit mycket tid och kan snabbt leda till problem. Detta beror på att egenutvecklad kod körs på servern i samma process som SharePoint själv. Följdeffekten kan då bli säkerhets- och prestandaproblem samt konflikter med inbyggda funktioner.

Microsoft har lanserat “Cloud App” modellen i samband med SharePoint 2013, en teknik där egen-utvecklade funktioner körs i en separat process och i vissa fall på en separat server i molnet. Samma teknik kan användas för att skriva “appar” till Office-program som Word, Excel och Outlook. Installation och avinstallation av appar kräver ingen nedtid för SharePoint-miljön och kan göras med ett musklick.

Som utvecklare kan man nu skapa appar som är lätta att installera, stödjer moderna webb-standarder som HTML5, OAuth, OData, jQuery och .NET 4.5. Appar kan även utvecklas i Open Source programspråk som exempelvis PHP. Appar kan testas separat, levereras från företages interna “app store” eller säljas via Microsofts publika “Market Place”, där man redan idag kan köpa många nya funktioner.

Har du tidigare utvecklat anpassningar för SharePoint är jag övertygad om att du kommer älska app-modellen! Informator leverar ett flertal utbildningar inom utveckling för SharePoint 2013.

Se samtliga utbildningar inom SharePoint här.

Vill du höra mer? Kom till seminariet App-utveckling i molnet med SharePoint 2013!

Jag får ibland höra följande kommentar från potentiella kunder ”vi ska jobba med Lean istället för ITIL nu”. Är det ett rimligt påstående? 

I mitt senaste inlägg förklarade jag hur ITIL förhåller sig till en rad andra ramverk inom området IT Service Management. Den här gången tänkte jag förklara kopplingen till Lean – i den mån det nu finns en sådan…

Innan jag går in på kopplingen mellan ITIL och Lean är en kortfattad beskrivning av Lean på sin plats. Det är dock inte helt enkelt eftersom det, till skillnad mot ITIL, inte är helt glasklart vad som avses med Lean. Ett populärt sätt att beskriva syftet med Lean är ”mer värde för mindre arbete” eller ”få bort allt slöseri som inte är direkt bidragande till värdeskapandet”. Lean är alltså inte något ramverk eller modell utan snarare en filosofi eller ett tänk. Detta tänk appliceras på olika sätt i olika företag och det kanske mest kända är det som Toyota anammat i sitt TPS – Toyota Production System. TPS vilar på fjorton principer som tillsammans bildar en helhet. Exempel på principer:

• Basera besluten på långsiktigt tänkande, även då det sker på bekostnad av kortsiktiga mål
• Skapa processflöden som för upp problem till ytan
• Standardiserat arbete är grunden till ständiga förbättringar och för personalens delaktighet
• Bli en lärande organisation genom att oförtröttligt reflektera och ständigt förbättra

Det är lätt att få uppfattningen att Lean endast är applicerbart på industrin, men det stämmer inte riktigt. Det går att anamma lean-tänket för vilka verksamhetsprocesser som helst. De som är baserade på ITIL, till exempel. Även om en IT-avdelning inte har samma processer som en biltillverkare så är slutmålet detsamma – att leverera en värdeskapande tjänst/produkt och att göra det så kostnadseffektivt som möjligt. En biltillverkare har processer för att förstå kravbilden från kunderna, designa bilen, tillverka bilen, marknadsföra bilen och sälja bilen på precis samma sätt som en IT-leverantör har processer för att förstå behov, designa tjänster, skapa tjänster, driftsätta tjänster, marknadsföra och sälja tjänster. Både en biltillverkare och en IT-tjänsteleverantör behöver även ha processer för service och support samt hantering av underleverantörer.
Det är lätt att inse att de principer från TPS som listas ovan är relevanta för en IT-avdelning och att de ligger väl i linje med ITILs syfte och budskap.

Sammanfattningsvis kan vi alltså konstatera att det finns en koppling, eller kanske snarare synergi, mellan ITIL och Lean. Vi kan även konstatera att kommentaren ”vi ska jobba med Lean istället för ITIL” är rent nonsens. Lean-filosofin behöver appliceras på processer och dessa processer kan mycket väl vara ITIL-processer.

Det pratas mycket om appar nuförtiden. De publiceras i Apple Store, Google Play, Windows Marketplace och på många andra ställen.

Nytt i Windows-världen är att så kallade native appar nu kan byggas i HTML5, CSS3 och JavaScript. Den som vill kan fortfarande använda "gammal" teknik som C#/XAML och då dra nytta av sina kunskaper inom exempelvis Windows Presentation Foundation. Nu ska vi inte lura oss själva till att tro att dessa HTML5-applikationer kan rullas ut till andra appbutiker än Windows Marketplace. Man är fortfarande bunden till Windows-plattformen, genom WinRT/WinJS. Men ändå, det är ett stort steg i riktning mot HTML5-baserad apputveckling, även på Microsofts plattform.

Samma sak gäller för iOS och Android, med ett tunnt lager native kod och resten HTML5-baserat kan man bygga appar som till 95% består av öppna standarder.

Firefox OS är ett mycket intressant initiativ som ytterligare kommer att påskynda standardiseringen av API-erna för hårdvara i smartphones och tablets. Alla appar i detta mobiloperativsystem är HTML5-baserade vilket gör det möjligt att enkelt bygga integrerade tjänster ovanpå plattformen, givetvis med HTML5 och dess relaterade tekniker.

När ska man välja native och när ska man välja HTML5? Det är än så länge en akademisk fråga, eftersom native fortfarande kan integrera med all hårdvara i smartphones och tablets. Men tro inte att det förblir så här länge till. Tack vare W3C's Device APIs Working Group Charter har vi öppna standarder på gång för kontakter, HTML mediainspelning, SMS, kalender, batteristatus, nätverk och rättighetshantering för enheter, som alla öppnar upp hård- & mjukvara för HTML5-baserade appar.

Jag förutspår härmed att 2013 blir året då den HTML5-baserade appen slår igenom på bred front.

Lycka till med Din framtida apputveckling!

Lyssna på MCT Mattias Asplund snacka om HTML5.


Här kan du se våra utbildningar i HTML5

Unika HTML5 -kurser utvecklade av amerikanska Kaazing, som ligger i framkant när det kommer till HTML5.
HTML5 Fast Track
HTML5 WebSockets
HTML5 WebSockets Workshop med flera.

Se samtliga utbildningar inom HTML5 här

I gårdagens inlägg påstod jag att ITIL är ett utmärkt verktyg men att det blir ännu effektivare om det kompletteras med andra ramverk och modeller. I dagens inlägg följer jag upp det påståendet genom att förklara hur ITIL förhåller sig till några av dessa ramverk.

Först en kort repetition av ITIL.
ITIL är ett dokumenterat sätt att arbeta med IT Service Management (leverans av IT-tjänster). Med stöd av ITIL kan man på ett effektivt sätt arbeta med utvecklingen av sina förmågor som tjänsteleverantör. Ramverket, som omfattar fem ganska tjocka böcker, beskriver hur man kan arbeta med tjänsteleveranser i fem livscykelfaser; Strategy, Design, Transition, Operation och Continual Service Improvement. I böckerna beskrivs ITSM i c:a 30 processer fördelat över de olika livscykelfaserna samt ett antal funktioner och modeller som stödjer processerna. Det finns beskrivningar över vilka roller som agerar i de olika processerna och även till viss del vilka aktiviteter de utför.

COBIT är ett ramverk för styrning och ledning av IT. COBIT har ett holistiskt verksamhetsfokus och syftar till att vara ett övergripande och sammanhållande ramverk för en organisations alla andra ramverk, modeller och standarder. COBIT kopplar t.ex. samman ITIL, ISO/IEC 27000 series, TOGAF, PMBOK/PRINCE2 och CMMI på en hög och övergripande nivå.
Ramverkets främsta syfte är att definiera vilka processer som krävs för att IT ska uppfylla ett företags affärsmål och används därmed som ett verktyg för kravställning, målstyrning och uppföljning av IT-verksamheten och dess processer. Man kan säga att COBIT talar om vilka krav affärsverksamheten ska ställa på IT-sidan medan ITIL beskriver hur de flesta av dessa krav ska uppfyllas.

ISO/IEC 20000 beskriver standarden för ett ledningssystem för IT Service Management och definierar kraven på de processer som behövs för en pålitlig tjänsteleverans. Ett företag som ISO-certifierar sig får en extern stämpel av ett audit-företag som bevisar att man uppfyller de krav som ställs enligt standarden. För att behålla certifieringen krävs återkommande revisioner.
Standarden täcker alla kärnprocesser inom ITSM och stöds av ITIL. Standarden består av en bok på 16 sidor som listar vilka krav som ska uppfyllas samt en bok på 34 sidor med lite utförligare beskrivning av kraven. Den stora utmaningen ligger i att kunna leda i bevis att kraven uppfylls vid en revision för certifiering enligt standarden.
Sammanfattningsvis kan man säga att ISO/IEC 20000 beskriver VAD som ska göras medan ITIL beskriver HUR det ska göras.

Pm³ är en förvaltningsstyrningsmodell vars syfte är att organisera förvaltningsverksamhet så att den kan bedrivas på ett affärsmässigt sätt. Modellen ägs och drivs av det svenska företaget På AB.
Modellen syftar till att effektivisera systemförvaltning med stark koppling till affärsverksamheten. I modellen bemannar t.ex. affärsverksamheten roller som är involverad i arbetet med systemförvaltning. Pm³ kan inte direkt användas för IT Service Management eftersom modellen baseras på systemförvaltning och inte tjänsteleverans. Omfattningen för modellen är betydligt mindre än det som definieras i ISO/IEC 20000, COBIT och ITIL. Styrkan i pm³-modellen är att den beskriver i detalj hur samverkan mellan IT och verksamheten ska gå till. På vissa ställen överlappar pm3 med ITIL och det är väldigt viktigt att tydligt definiera hur modellerna ska samverka.

Olingo har tagit fram ett white paper som beskriver kopplingen mellan ITIL och andra ramverk mer i detalj. Om du vill ha ett exemplar så får du gärna ta kontakt med oss så skickar vi det kostnadsfritt.

I nästa inlägg tänkte jag försöka mig på konststycket och beskriva kopplingen mellan ITIL och Lean... om det nu finns en sådan.

Det finns ett engelskt uttryck som kan översättas till "om allt du har är en hammare kommer allt se ut som en spik”.
Det har varit många företags inställning till ramverket (verktyget) ITIL - alla IT-avdelningens utmaningar ska lösas med hjälp av ITIL.

För några år sedan räckte det med att kunna stava till ITIL för att bli hälsad som en frälsare. ITIL var lösningen på IT-avdelningens alla problem. Man skulle bli bättre på att förstå kunden, kostnaderna skulle sjunka, driftsäkerheten öka och medarbetarna skulle bli lyckligare.
Idag har flera företag vaknat upp från sitt ITIL-rus till en ganska kraftig baksmälla. Vad var det som hände?
Det som hände var minst ett av nedanstående alternativ, troligtvis allihop:

• Oförmåga att inse att ITIL är ett verktyg och ingen färdig lösning
• Orimliga förväntningar på organisationens förändringsförmåga
• Bristande kunskaper hos egen personal OCH externa konsulter

Jag hävdar med en dåres envishet att ITIL är ett mycket effektivt verktyg. Men man måste förstå hur det ska användas och inse att världen inte bara består av spikar.
Det finns många ramverk och modeller som är alldeles utmärkta, och nödvändiga, komplement till ITIL. Några exempel som kan nämnas är COBIT, ISO/IEC 20000, CMMI, Balanserat Styrkort, PM3 samt Lean. Dessa verktyg ersätter dock inte ITIL utan de har andra styrkor. Med flera verktyg i verktygslådan ser inte allt ut som en spik längre. 
 
I min nästa blogg tänkte jag berätta lite mer om hur några av ovanstående verktyg kompletterar ITIL.  Det blir ett lite längre inlägg som jag hoppas du tar dig tid att läsa. Bra koll på verktygen ökar möjligheterna till ett lyckat bygge!

It's already been a year since I first started teaching C# Masterclass. In that time, I have taught it more times than any other course. This makes me happy, because it's a great deal of fun to teach. I deliberately put a very wide range of topics into the course, because I believe that being a great developer demands a great range of knowledge.

As well as doing a lot of the Obvious Things - like talking through good use of OOP, generics and lambdas - I sneaked in lots of those topics that are rarely talked about, like Unicode and the hidden gotchas of .Net strings, how CPU caches determine parallel performance, and the System.Threading.Interlocked class With the arrival of C# 5, I decided it was time for an update.

Because a C# master should knows how to put the latest new keywords - async and await - to good use, right? So, from now on, there will be a section on asynchronous programming: what it is, why it's interesting, what can makes it annoying and fiddly to do, and how the new features in C# 5 help us to cope with it. By the end, you'll know how to write an infinite loop on a program's UI thread, while staying responsive! And if that ain't a great C# party trick, I don't know what is. Thanks to everybody who has come along over the last year - it's been a lot of fun. I look forward to another year of teaching the C# Masterclass, now with C# 5 coverage. Want to come along? Check out the course description, then be sure to give us a callback! :-)

/Jonathan Worthington
http://www.jnthn.net/

Artikelserie - del 3 av 3. Bengt Karlöf: "Man kan med fog påstå att management är ett så komplext ämne att det inte enkelt låter sig behandlas med sedvanlig vetenskaplig metodik - mycket beroende på att management är en yrkesroll snarare än en vetenskap".

Om man utgår från att management består av de tre huvudkomponenterna; leda, styra och utveckla en verksamhet, så kan dessa element ställas i relation till varandra och till beprövade koncept och ämnesindelningar. En naturlig utgångspunkt är ämnet företagsekonomi som det undervisas på ett drygt tjugotal universitet och högskolor i Sverige.

Företagsekonomi består av ämnesdelar som finansiering, marknadsföring, redovisning, analys etc. Många studenter delar säkert min upplevelse då jag en gång började på Handelshögskolan i Stockholm – nämligen svårigheten att få en överblick över hela ämnet och sambanden mellan ämnesdelarna.
Några av mina kurskamrater fortsatte att läsa företagsekonomi. Det visade sig då att ytterligare och fördjupade studier koncentrerade sig kring en specifik ämnesdel, vilket sålunda ger ett snävare perspektiv på management av en verksamhet. Om man studerar vidare och så småningom doktorerar så sker detta nästan alltid med en liten delmängd av helheten som föremål. Ytterligare studier leder sålunda till ökad specialisering. På flera lärosäten saknas en institution eller professur som behandlar helheter vare sig detta benämns strategi, management eller ”business policy”.
Den del som väljs ut för fördjupade studier kan då studeras med metoder som kan göra anspråk på att kallas vetenskapliga. Om någon enskild faktor sålunda isoleras så kan man i analysen bortse från alla de störningar som föreligger i en verklig managementsituation. Man kan med fog påstå att management är ett så komplext ämne att det inte enkelt låter sig behandlas med sedvanlig vetenskaplig metodik - mycket beroende på att management är en yrkesroll snarare än en vetenskap. Detta utgör inget skäl att försumma området – speciellt som så många miljoner människor i världen ständigt brottas med denna komplexa materia.

Stort gap mellan forskning och praktik

 

En faktor att beakta vid behandling av ämnesområdet management är att det kräver ett stort mått av erfarenhet för att ge kunskap om en stor del av de komplexa samband som man behöver beakta. Problemet är sålunda att det svårligen går att låta studenter utan erfarenhet behandla ämnesområdet som ett led i exempelvis en forskarkarriär.
Den kände krönikören Michael Skapinker skrev om företagsekonomisk forskning i Financial Times 2011 under rubriken ”Varför näringslivet inte bryr sig om forskning vid handelshögskolor”.
The Academy of Management är världens ledande förening för akademiker med 18 000 medlemmar i 104 länder. I sin tidskrift Academy´s Learning & Education Journal argumenterar man mot kritiker som hävdar att forskning från handelshögskolor är irrelevant för affärslivet.
Skapinker hade i en tidigare artikel hävdat att det inte finns någon yrkesgrupp i vilken gapet mellan forskare och praktiker är så stort. Inom medicin, teknik och juridik ägnar sig akademiker energiskt åt sina respektive professioner medan forskning vid handelshögskolor inte tilldrar sig chefers uppmärksamhet. Artikeln ingick i en serie i vilken professorer tillstod att få brydde sig om deras forskning.
Den tilldrog sig större respons än någonting han skrivit på 30 år och det mesta kom från akademiker vid handelshögskolor som medgav att chefer generellt sett ignorerade dem.
Man angav tre skäl. För det första är management inte en disciplin som medicin, juridik  eller teknik som resulterar i en examen, medan chefer inte behöver någon formell kompetens.
För det andra är management inte en vetenskap. Medicin och teknik kan studeras med rigorös vetenskaplig metodik medan mänskligt beteende och affärer var oförutsägbart och därför svårt att forska på.
För det tredje är ekonomiska institutioner angelägna att bli respekterade av andra akademiker och känner sig nödsakade att frambringa den slags forskning som godtas av universitet. Fakultetsmedlemmar förklarade att de inte skulle kunna fortsätta inom akademin om de skrev böcker som chefer faktiskt ville läsa.
Management må vara snarare en konst än en vetenskap men det finns mängder av områden som chefer skulle vilja veta mer om, t.ex. om 360-graders utvärdering medför någon nytta eller om företag som anlitar säljpersonal i Indien lyckas bättre än de som använder egna återförsäljare. Resultaten kanske inte blir lika robusta som medicinsk forskning men de skulle väcka intresse och diskussion.
Föreningens (Academy of Management) senaste konferens hade teman som ”Utforskning av paradoxer inom organisatoriska kontext” eller sådant som akademiker verkligen vill veta: ”Forskning finansierad genom donationer”.
Medicinska och juridiska forskare ägnar sig åt för professionen relevant forskning och vad hindrar professorer vid handelshögskolor att utföra relevant forskning när de en gång fått sina positioner? Frank Vermeulen vid London Business School skrev nyligen i Financial Times att det är inte endast så att forskningen vid handelshögskolor inte når chefer utan den används inte heller i undervisningen!
Den av Skapinker beskrivna situationen ovan gäller inte i första hand Sverige men onekligen finns fragment i hans återgivning som är relevant utanför Storbritanien.
Låt oss av dessa skäl omfamna management och utveckla kunskaper inom detta vittomfattande kunskapsområde, såväl inom högskolesektorn men kanske framför allt i form av möjligheter till yrkesmässig fortbildning inom ett område som en mycket stor andel av den yrkesverksamma befolkningen konfronteras med alldeles oavsett utbildningsbakgrund.
Det räcker sålunda inte med att begränsa kunskapsutvecklingen inom management till någon speciell fakultet så den gäller så brett.  Man måste skapa tilläggsutbildningar som når alla dem som får ansvar för att leda, styra och utveckla en verksamhet.

/Bengt Karlöf
 www.karlof.org 

Managementfrågor berörs sällan i debatten trots att området har och har haft en avgörande betydelse för tillväxten för först de västerländska samhällena och nu även för tillväxtekonomierna i Asien och Sydamerika.