Tag Archives: development

Still not automating tests? Here’s why you should (again)!

Posted on by

The other day I read a blog by Uncle Bob. It more or less stated that no matter what situation you are in, writing automated tests will make you go faster. Ok, this is old news I thought, until I checked Uncle Bob’s tweets. A fair amount of people argued against this statement, and that surprised me!

Campfire

Join me at the campfire!

So I started thinking about why there still are fellow software developers that doesn’t believe in automated testing? Have they not seen them in action and understood what they are for? Please, gather around the campfire, and I will tell you one, just one, of my war stories, and then I will tell you why also you should write automated tests!

read more »

A team experiment with and without offshoring

Posted on by

A cross-functional team I was working with last year had three testers offshore in India. The rest of the team (about 15 people) was co-located here in Stockholm.

Some team members had a nagging feeling that they could go so much faster if the testers also moved to Stockholm so they went to their boss and asked. The reply was that testers are so much less expensive, by a factor 2.3, so it was not possible, unless they could settle with fewer testers.

So they decided to do an experiment for a few months. They moved one of the testers from India to Stockholm and dropped the other two testers (re-allocating the other two to other teams) to see how that would work.

read more »

The Future of Software Development

Posted on by

Whar are YPU doning in the future?

What will software development be like in the future? “Agile” as we know it, will not be around, nor will test-driven development, continuous delivery, or BDD-like methodologies. I’ve been pondering this for a while, and based on some observations and a dose of wishful thinking, I’ve arrived at the conclusion above. Do you agree?

read more »

Backbone: Orderly JavaScript

Posted on by and

Backbones aren’t the usual fare for tech blogs, but if you’ve been following frontend development, then you’ll have heard of Backbone.js. From their site: Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions,views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface. read more »

How to hire a real star developer

Posted on by

What makes the difference between a star developer and a day coder? First of all, with a star developer I don’t mean star as in ”famous”, rather as in ”elite”.  And, a day coder is OK to be, no disrespect here. We need you as much as we need the elite.

My point here is that if you wish to hire a real star, you need to know what to look for.

read more »

Learning, understanding, and horizontal development

Posted on by

As developers feel the daily pressure to deliver, they tend to skip a crucial step in the process: learning and understanding the system. There’s a huge difference between just adding more lines of code to the codebase and making changes that maintain the conceptual integrity of the system.

Horizontal development is the result of not spending enough time learning and understanding the system you’re working on. By starting to churn out code too soon, you’ll inevitably be adding silos of functionality in parallel to existing functionality.

The outcome is legacy code. It doesn’t matter how well factored it is, and what test coverage it has!

read more »

Why Scrum is better than Kanban

Posted on by

I have for some time been thinking, what is best, Kanban or Scrum. I can’t make up my mind so I decided to write two blog entries, one where I have the "I love Kanban" hat on me and one where I’m wearing a "I love Scrum" T-shirt.
My conclusion is, not very suprisingly, that  it depends on the situation.

In this entry I take the Scrum T-shirt on. Click here if you like to read the one where I love Kanban.

I concentrate on some area where Scrum and Kanban differs:
Iterations – In Scrum you work in iterations, Kanban sees development as a forever ongoing flow of things to do.
Commitment – In Scrum team commits to what they will do during a sprint
Estimations – In Scrum you must estimate. In Kanban it’s optional.
Crossfunctional teams – That’s one of the pillars of Scrum. For Kanban it’s optional.
Prioritized backlog, self-organizing team, transparency, inspect & adapt, pull scheduling and good communication/collaboration are things they have in common.

By asking team for a commitment they will get a positive stress knowing that people from outside will see if they can do what they committed to. It also gives an extra energy at the end of the sprint when team have the goal within reachable distance. After the sprint, the team can feel relaxed and gather some new energy for the next sprint. It’s psychologically nice to not feel you are in the middle of a never ending stream of things to do. Instead Scrum concentrates on one sprint at a time and give possibility to focus only on those things, decided to take in to the sprint. By working in fixed length iteration you get a nice rhythm the whole company can feel and adapt to.

Estimating is not waste since valuable information is transferred from product owner while the team ask what is needed to know what they are estimating. The same thing with commitment. To be able to commit they need to know what they are committing to. They simply have more interest of getting information from product owner.

Even though you can predict when a project is done just by counting stories left it is more precise if each story is estimated as well. Prediction is important when more departments, like marketing, is dependent on your work. It gives a more serious feeling.

If there are some time at the end of a sprint that’s valuable even if no new features are developed. This is time developers can use to improve code quality or development environment. Both will give better efficiency in the long run.

Working together in a cross functional team is a psychological thing. You are able to go the whole way from concept to released product together as a team without dependences. You are not just a cog in the machinery. It’s also fun and helps you grow as a person. By helping each other, knowledge is spread which gives less person dependency. It also helps prioritizations since features can be built without considering which knowledge is available. To coordinate between people with the same skills but sitting in different teams you can have virtual teams meeting as often as needed.

Please, help me Scrum-fans, what have I been missing?

Best regards,
Tomas

Why Kanban is better than Scrum

Posted on by

I have for some time been thinking, what is best, Kanban or Scrum. I can’t make up my mind so I decided to write two blog entries, one where I have the "I love Kanban" hat on me and one where I’m wearing a "I love Scrum" T-shirt.
My conclusion is, not very surprisingly, that  it depends on the situation.

In this entry I take the Kanban hat on. Click here if you like to read the one where I love Scrum.

I concentrate on some area where Scrum and Kanban differs:
Iterations – In Scrum you work in iterations, Kanban sees development as a forever ongoing flow of things to do.
Commitment – In Scrum team commits to what they will do during a sprint
Estimations – In Scrum you must estimate. In Kanban it’s optional.
Crossfunctional teams – That’s one of the pillars of Scrum. For Kanban it’s optional.
Prioritized backlog, self-organizing team, transparency, inspect & adapt, pull scheduling and good communication/collaboration are things they have in common.

Kanban is Lean and has been around for 50 years and has shown to be successful. Things are seen as a flow without iterations. Not many rules. It’s just a focus on reducing work in progress, strict prioritization and limiting demand after capacity. Besides that you have the normal Lean principles of quality, just-in-time (quickly from concept to cash), Kaizen (continuous improvement) and minimizing waste. No meetings if it’s not adding value to the customer. Most of those things are fine with Scrum but I can sometimes think Scrum has some waste. Here I will mention some areas were Scrum practices can be waste.

Estimations – If product owner knows what needs to be done and the only interest is to have it done a soon as possible, why spend time on estimating? In Scrum, estimations are needed for team to know how much to commit, to calculate velocity and for product owner to decide on prioritization. If none of this is needed, it’s waste and we shouldn’t do it. If you like to measure velocity you can instead count number of stories done per week or month. While talking about measurement why not look at something the customers are interested in, cycle time. That is, the time it takes for the customer to get what he or she ordered.
 
Last day in Sprint. If team is done with a story and there is not enough time left in the sprint to complete the next, it’s likely no one works hard the remaining time and that’s waste.

In Scrum, the team commits which does not work very well for a team with support issues. They get a lot of disturbance and commitment is not worth anything since the ones disturbing them doesn’t care about commitment. A commitment you can’t control gives either frustration and stress or demotivation.

In Scrum a team is crossfunctional and sits together with the people working with the same project and not with the ones with the same knowledge. Let’s say you work with sound effects for a computer game. Then it’s not much help to have a java-programmer beside you. It would be more valuable to sit with people doing the same things as you do who can help you with tools and practises.

Please, help me Kanban-fans, what have I been missing?

Best regards,
Tomas

Lean för mjukvara på 10 minuter

Posted on by
Lean handlar om att bli snabb genom att sluta göra onödiga saker.

Lean ser det som vi producerar som ett arbetsflöde. Ett arbetsflöde startar med en idé som en kund vill ha gjort, och slutar med leverans till kunden, från Concept to Cash. Lean strävar efter att ta bort allt onödigt som sinkar och stör detta arbetsflöde så att tiden det tar från beställning till leverans är så kort som möjligt.


Lean handlar om att minimera tiden från att vi har en idé/beställning till vi har producerat det som någon är beredd att betala för.
Cykeltiden är hur lång tid det tar från det att en kund kommer med ett önskemål, tills dess att hon fått det levererat (och är beredd att betala för det).

För att kunna optimera cykeltiden kikar man på vilka flaskhalsar och köer som finns i arbetsflödena i en organisation.

Ett enkelt sätt att hitta de flaskhalsar man har är att kika på var vi har saker på hög, var är våra köer? En kö bildas alltid före en flaskhals.

Efter en kö finns det alltid en flaskhals.


Var någonstans ligger halvfärdiga saker på hög? Ligger de i bugghanteringssystem, orderhanteringssystem, otestad mjukvara eller i kravspecifikationer? Vilken flaskhals är det som kommer direkt efter denna hög?

Lean handlar om att identifiera dessa flaskhalsar, se till att de försvinner och skapa ett jämt flöde. Ett flöde som därigenom på kortast möjliga tid och med minsta möjliga resursåtgång levererar det kunden vill ha.

Lean värdesätter det som levereras och inte det som påbörjas. Att få saker ur händerna istället för att jobba hårt.

Många företag arbetar enligt filosofin att hela företaget går bra om alla delar arbetar effektivt och hårt. Lean optimerar istället på helheten och mäter cykeltiden, from concept to cash, vilket inte nödvändigtvis är samma sak. Låt oss ta ett exempel. Här nedan är en ögonblicksbild av ett arbetsflöde.

Vi har tre stationer. Vid varje station arbetar man optimalt och hårt. Trots det ligger saker i kö. Vi har station A där det i genomsnitt tar 1,5h att genomföra en sak, och där det för närvarande ligger 3 saker i kö och väntar. Station B där man är två som arbetar och är överbemannad och därför inte har någon kö, och det tar i genomsnitt 1/2h att göra en sak. Station C där det tar 2h att göra en sak i snitt och det ligger 3 saker i kö.

Låt oss säga att alla arbetar heltid. Då har vi en arbetstid på 160h i veckan (4 personer á 40 h). Vi slutför 20 saker i veckan eftersom sista stationen C levererar en sak varannan timme. I genomsnitt tar det 14,5h från start till mål att utföra en sak (summan av hur länge en sak ligger i kö + göra tid). Antal saker som vi samtidigt arbetar med är 9 vilket är alla saker vi arbetar med plus de saker som ligger halvfärdiga i olika köer (4+1+4).

Arbetstid 160 h
Tid genom systemet 14,5 h
Levererade saker i veckan 20 st
Antal saker på gång samtidigt 9 st

Låt oss nu begränsa mängden som vi arbetar genom att anpassa oss efter flaskhalsen, station C. Vi tillåter helt enkelt inte att A och B producerar så länge det finns en kö i C utan tvingar dem till att vila.

Vi har nu den totala arbetstiden fortfarande 160h, men utav den vilar vi i stationerna A och B totalt 70h (10h + 2*30h) per vecka  och vi producerar fortfarande 20 saker i veckan. Däremot har vi färre saker i systemet, nu endast 3 saker åt gången (inga köer). Tiden det tar från att vi börjar med något tills det är klart för leverans har sjunkit från 14,5h till 4.

Med köer Utan köer
Arbetstid 160 h 160 h
Tid genom systemet 14,5h  4 h (mer än tre gånger så fort)
Levererade saker i veckan 20 st 20 st
Antal saker på gång samtidigt 9 3 (en tredjedel)

Om vi låter flaskhalsen styra hur mycket var och en ska producera får vi alltså

  • Lika mycket levererat
  • Leverans till kunden tre gånger så fort
  • Färre saker att hålla reda på

Pausa lite här och reflektera, detta är inte intuitivt: Genom att jobba mindre levererar vi snabbare!

Men vi slutar inte med detta, låt oss optimera flödet. Vi har ju två personer på station B som inte behöver vara fler än en. Vi flyttar en av dem till flaskhalsen C och ser vad vi får för resultat.

Nu har vi fortfarande 160 timmars arbetstid men tiden att inte göra något gäller nu B och C medan A går för fullt. A är alltså den nya flaskhalsen som bestämmer hur mycket som produceras. Då den blir klar med en sak på 1,5h så blir antal levererade saker per vecka 40/1,5 = 27. Tid genom systemet är 3,5 timme och antal saker som man arbetar på är fortfarande 3.

Med köer Utan köer Optimerat utan köer
Arbetstid 160 h 160 h 160 h
Tid genom systemet 14,5h 4 h (tre gånger så fort) 3,5h (ytterligare lite snabbare)
Levererade saker i veckan 20 20 27 (35 % förbättring)
Antal saker igång samtidigt 9 3 (mindre än hälften) 3 (oförändrat)

Efter att ha identifierat flaskhalsen och åtgärdat den har vi alltså ökat det vi levererar med 35% och jämfört med vårt utgångspunkt levererar vi fyra gånger så fort.

För att sammanfatta strategin ovan

  1. Begränsa arbetet som var och en gör så att igen producerar mer saker än vad som behövs i det totala flödet (limit work to capacity).
  2. Identifiera flaskhalsen.
  3. Åtgärda flaskhalsen

Lean handlar om att få detta att fungera.

Exemplet ovan är taget från typiskt fabriksarbete, men om man ser sakerna som för sig i flödet som en funktion som ska läggas till i en mjukvara, där station A kan vara någon form av krav analys, station B kodning och C testning så stämmer resonemanget även inom andra områden. Om du vill se ett sådant flöde i praktiken, gå in på en lunchrestaurang i rusning, till exempel Subway.

Planning ahead in Scrum

Posted on by

In Toyota Production System (TPS) action takes place through the Plan-Do-Check-Act-Cycle

Plan-Do-Check-Act

If we relate this to Scrum we see a lot of emphasis on the Do, Check, Act part. But not as much on the plan part. Planning is usually explained as a an activity that takes place on sprint planning day where both team and product owner are participating.

However, how do we deal with situations like:

  • stories that require a multi team effort
  • interfaces to third party systems

..and given a definition of  done "running in production" are we answering questions like:

  • are we implementing the right solution to our problem?
  • is our delivery useful to our recipients?
  • have we got access to necessary resources?
  • can we test? can we deploy?

Basically we need continuously run a thought process in the sprint before we do the implementation. Typically a development team spend around 20% of their time planning for their implementation (Mary Poppendieck).

Thinking ahead
The deliverable for the thought process is "story has business value and is estimatable"
So how do we go about?

Option 1: Use scrum master as an analyst
Appoint the Scrum master as the responsible person for dealing with forward thinking.

Pro’s:

  • SM is already a contact point
  • He does not suffer as much from interupt control as other team members

Con’s

  • Not always the correct technical person for solutions
  • Team can feel overrun

Option 2: Use an external analyst
Get a dedicated analyst in the team that always looks forward.

Pro’s:

  • Releaves team from communication stress

Con’s

  • Adds an extra handover step (waste)
  • Needs to be a superb communicator with team.
  • Analysts tend to lean over to business focus
  • Communication issues remain hidden

Option 3: Assign a "look ahead" story for each sprint
Insert a story which makes next sprint stories estimatable.
Team can pick tasks from this story in same way as on normal stories.

Pro’s:

  • Team can choose among the stories in normal scrum way
  • Communication issues are surfaced
  • Bonding to outside parties is preserved in team

Con’s

  • Product owner needs to have a forward vision
  • Team members might need training in communication skills
  • Implementation might suffer if extensive travel is required

My personal preference is with the option #3. But I have also seen option #1working in Scrum teams. The bottom line is that you need to think this through or you might end up building software that does not deliver intended business value.