• About me

    JensI have been working as a software consultant for more than 11 years. Because of that I am an eager supporter of lean principles and agile methods.

  • Recent Posts

  • Recent Comments

    • Code Monkeyism: time. Too many developers on the other hand lead to communication overhead and get ineffective says...
    • Websites tagged "scrum" on Postsaver: - Speaking at Nordic Scrum Forum saved by speechjon2009-09-03 - Drury snaps...
    • Erik Lundh: Well “XP expert” sounds a little odd. XP was a vehicle for getting agile teams started in the...
    • The Flex Person: Well, just a single look at the restaurant you are referring to makes me want to pack by bags and...
    • Jens: Thanks Johan, I applied for the prezi beta testing like you recommended. I might post an example if I manage to...
  • Archives

  • Blogroll

  • Meta

Archive for January, 2006

Another Tax Payer

Posted by Jens on January 20th, 2006

Vi hade ett planerat kejsarsnitt till fredagsmorgonen, och på torsdagkvällen var vi och lämnade Filip till mormor och morfar, när vattnet gick. En ambulansfärd senare får de bråttom på sjukhuset och en stund innan plan levereras en välskapt liten pojke med ett kejsarsnitt. 3460g, 50cm och lika snygg som sin far.

Coaching Tool: 360 Degree Feedback

Posted by Jens on January 17th, 2006
  1. What are your skills?
  2. What do you believe other people think are your skills?
  3. What do other people really think are your skills?

If you have any self-awareness you can easily answer the first question. You can at least get your own view of it, and with that self-awareness you are probably quite accurate. The second question is also yours to answer. It tells how you believe other people perceive you. The last question others must answer, since it is how other people really perceive you.

To compare the answers from the three slightly different questions could be very interesting. If they are matching it could mean that you have excellent self-knowledge and that you act who you are.

If your own apprehension differs from what other people think, they might not have the correct apprehension about you. But others will treat you according to how they apprehend you, regardless if its correct or not. If you want others to apprehend you like you think you are and treat you accordingly, you must also act who you are.

To really investigate this is called a 360 degree feedback and is common within coaching. It is done by letting people around you, e.g. in your project, fill in a questionnaire (anonymously). Since I coach a handful of people within our organisation that are having key assignments, I have started to put together a 360 form of my own. It’s not ready yet, but the concerned persons will know when it is.

Read more about coaching:
Coaching for Performance, John Whitmore

Coaching för bättre resultat, John Whitmore (på svenska)
Coaching the Alpha Male

Project Retrospective II

Posted by Jens on January 11th, 2006

In this project I was brought in after a restart of a project that was lacking any development methods, although the rest of the organisation had a heavy RUP adaptation. My role was again as a Business Analyst collecting requirements from the business people, but this time I also had to create requirement working routines. I was also asked to help creating a working overall development method. I took the liberty to introduce some agile ideas.
I gave them the 30 day iteration, the product backlog, the sprint backlog, the Scrum meeting and helped them with planning day and created all the planning templates. It was well received and I had hopes of introducing the rest of Scrum, but unfortunately the project manager never understood the full picture and as soon as I turned my back on him he copied the plan into MS Project, forever hiding it from the rest of us. I guess he felt the threat of being obsolete and that’s understandable.
I was also met with the challenge that the project was spread over three different locations, which is not ideal in agile projects. I suggested that each site had their Scrum meetings and then the site responsibles had a “scrum of scrums”.
One experience I can draw from this is that it’s probably easier to introduce Scrum being the project manager myself.

Update: The project Manager has, shortly after my assignment ended, decided to leave the company, leaving the project in a total mess.

Get the advantage of knowing how to solve the complex issue of developing software using a deceptively simple method:
Agile Software Development with SCRUM
Agile Project Management with SCRUM
Scrum

Fixed price contracts - a loose-loose situation

Posted by Jens on January 7th, 2006

En väldigt vanlig situation är att man lägger ut en upphandling till flera anbudsgivare där man begär ett fast pris av anbudsgivarna. Detta är ett av de sämsta sätten att genomföra en upphandling därför att bägge parterna förlorar på det.

För att kunna ge ett fast pris med precision krävs det att man har en komplett kravspec så att man vet vad det är som skall utvecklas. En sådan kravspec får man aldrig av det enkla skälet att det är omöjligt att göra en. Ibland har det gjorts en ansats via en tidigare gjord förundersökning, eller så inleder man anbudsprocessen med att göra en förundersökning. Denna leder på sin höjd till en grov modell av vad som förväntas, något som sällan hjälper anbudsgivarna att göra en gissning av utvecklingskostnaderna. Redan här har man angripit problemet med en ansats till vattenfallsmetoden. Empiriska undersökningar och hittills gjorda erfarenheter visar att vattenfallsmetoden inte fungerar. Bla visar en undersökning av Standish Group att då man har kraven ”upfront” så visar det sig att 64% av funktionaliteten aldrig eller mycket sällan används. Man lägger alltså ner väldigt mycket resurser till ingen nytta alls.

Oftast finns det en tanke om att de olika anbudsgivarna konkurrerar om anbudet så att man därmed hoppas pressa priset så mycket som möjligt, i god kapitalistisk anda. Men för att en tillgång-efterfrågemodell skall fungera krävs bla att varorna som jämförs från de olika leverantörerna är identiska. Det är de garanterat inte i detta fallet eftersom den bristfälliga kravbilden gör att de olika anbudsgivarna kommer att skissa på var sin unik lösning, vilket gör det knepigt att jämföra alternativen.

Inte helt sällan är det någon anbudsgivare som ”dumpar” priset därför att man av något strategiskt skäl vill ha uppdraget; man kanske vill ha en meriterande ny kundreferens. Det kan vara att man förväntar sig en merförsäljning antingen till samma uppdragsgivare eller en försäljning av samma koncept till andra med samma behov. Det kan vara en ren överlevnadsfråga. Oavsett anledning betyder det oftast att man i någon mening underskattar arbetsbördan och en bit in i projektet har man förbrukat de budgeterade timmarna samtidigt som det återstår en hel del utvecklingsarbete. I detta läget saknar man incitament för att fortsätta göra ett bra jobb och kvalitén på arbetet blir tveklöst sämre. Man får ju inte längre betalt för att fortsätta jobba i uppdraget och man kanske ersätter en erfaren lättsåld person med en oerfaren som man samtidigt passar på att lära upp. Uppdragsgivaren tycker att han har gjort en bra affär, men i själva verket skjuter han sig själv i foten.

Hur skall man göra då? Jag skulle önska att en uppdragsgivare istället för att sträva efter att hitta det billigaste priset istället skulle sträva efter att hitta den bästa samarbetspartnern. Man skall alltså försöka hitta den anbudsgivaren som passar bäst ihop med den egna organisationen, den anbudsgivare som man tror har bäst förutsättningar att kunna leverera den produkt man önskar, och det varierar ju från fall till fall, precis som med personkemi. Jag skulle också gärna vilja se att man väljer en anbudsgivare som har erforderlig domänkunskap, en som har gjort det förr, som har stött på problemen tidigare och känner igen dem. Det handlar i grund och botten om att skapa ett förtroende mellan uppdragsgivaren och uppdragstagaren. Man måste bygga ett partnerskap för man löser uppgiften endast genom att samarbeta, inte genom ändlösa kontraktstolkningar och förhandlingar.

För att detta skall fungera måste man jobba enligt någon lättrörlig utvecklingsmetod, långt ifrån vattenfallsmetoden. Scrum tror jag är den metod som har bäst förutsättningar att lyckas med detta upplägget. Man jobbar alltså i 30-dagars iterationer och man driftsätter en delleverans efter varje iteration. På så sätt får uppdragsgivaren feedback var 30:e dag och han kan i sin tur ändra projektets riktning var 30:e dag i precis den riktning han önskar. Det är enkelt att räkna ut och fakturera en fast kostnad för en iteration eftersom en iteration är timeboxad. Uppdragsgivaren skall också ha en möjlighet att avsluta projektet och samarbetet vid varje avslutad iteration om samarbetet inte fungerar. Endast så kan man bygga upp ett starkt förtroende, och om anbudsgivaren inte är beredd att ställa upp på det har han inte tillräcklig självkännedom, eller rent mjöl i påsen.

Jag började skissa på denna posten på svenska, sen fortsatte jag av bara farten. Om det finns behov översätter jag den.
I started outlining this post in Swedish and then continued unintentionally. If needed I will translate it.

Bloggtoppen.se