Category Archives: Scrum

What Developers Need to Know About Agile

Agile is mostly driven driven by managment and consultants, seldom bottom up by developers. Some developes are suprised about agile and don’t know how to react. Lots of literature is written about agile, but very little with the developer in mind. What do you need to know about agile as a developer?

I’ll primarily talk about Scrum as the most successfull (in term of adoptions) agile method, but most applies to other agile methods.

What developers need to know about agile

  1. Much less crunch time due to better estimation, more detailed and better planning. Agile is often pull instead of push, so developers pull their work from a product owner, contrary to work pushed onto them by managment (see below). Because features are no longer pushed and there is no abitrary deadline, there is a lot less crunch time. Crunch time happens if agile teams underestimate the work or overestimate their ability. Over time estimation gets better and crunch time at the end of a sprint vanishes.
  2. More working on features. Developers in agile are not working on whatever someone wants, whatever comes to managments mind in the morning after getting up. Agile has better planning and the backlog in Scrum leads to less chaos and more predictability. But because stories and iterations are short, product management is more agile as before.
  3. Less meetings. All meetings in Scrum are pre-defined meetings and include daily standups, estimations and planning. There are much less ad-hoc meetings, meetings are time boxed and are shorter, all meetings have a clearly defined purpose with defined work results. So I consider meetings in Scrum not “meetings” but real group work. There are especially less panic status meetings because there is no crunch time.
  4. Pull not push. Developers pull features (stories) from a product owner during a planning session. They pull as many as they can do. Requirements are not pushed from customers or product management. Pull as many as you can do, strife for increasing your work.
  5. Be a critic. Agile expects you to be a critic with requirements. Your opinion is needed, there is no push in requirements. Martin Fowler writes in Conversational Stories:

    In terms of coming up with stories, what this means is that they are always something to be refined through conversation – and that developers should play an active role in helping that definition.

    Good stories follow the INVEST principle: I – Independent, N – Negotiable, V – Valuable, E – Estimable, S – Small, T – Testable. Negotiable means your opinion as a developer is needed.

  6. Agile makes you happy. There are problems in agile, and things developers need to adapt to and usually do not like at first. But in all teams I’ve worked with, satisfaction went up after the introduction of Scrum and most developers – though not all – want to stay with agile after it’s introduction.
  7. Responsibility as a team. The team wins or fails, not individual developers. The team has committed itself to stories, all developers have promised to finish those stories in the next sprint. Don’t take this lightly, it’s a major shift in responsibilites. Help each other, it’s no longer “We failed because A didn’t do B.” If the team failed, you failed.
  8. Agile is about working, high quality code. The result of agile is working, high quality code. Quality is king, pull only as many stories as you can do with high quality. Do not sacrifice quality. The pull principle (see above) gives you enough leverage to not compromise on quality. Live for software craftmanship.

Agile is a different way for thinking. Embrace agile as a developer, it will change your life and make things easier (and only some things harder) and make you love your work and your profession more.

Development Dream Teams

Over the years I’ve build some teams. The size and composition most often was determined by the company I was working for. This meant the team was developer only, at least some teams were cross-functional. I wished to have the freedom to create an optimal development team, a dream team.

In modern teams everyone should be able to do everything – this avoids bottlenecks or single point of failures and distributes the burden of some tasks. But there are limits. Skills are not easily found combined in one person:

  • Test Know How
  • UX/Design CSS
  • Programming
  • Product Development / Management

So a cross functional team needs to include:

  1. Product manager / PO for product development, wire frames, business analyist, business cases
  2. UX/HTML designer for usabilty, design and hardcore CSS problems, developers can’t solve
  3. 5-7 Developers for programming, backend, frontend, CSS/HTML, development, unit testing
  4. QA/tester: works with PM to determine acceptance tests, writes automatic acceptance tests, exploratory testing, helps developers with their tests, keeps the testing focus
  5. Optional, but helpful: Operations guy for the sub system. This role can be temporary

Why strive for a cross functional team? When a team is not cross functional, there is a lot of communcation overhead and lots of filled queues. With no product manager as part of the team, there are vertical silos and handoffs. Repsonsibility is split and in the case of trouble, finger-pointing starts.

And Jon Moore blogs in “Scrum thoughts: cross-functional teams”:

As a developer, this was great. We had instant access to team members from the other disciplines, able to brainstorm about how a feature should work and getting questions answered quickly. There was a very real team vibe, very exciting. […] The six weeks that we operated like this were really fun!

With cross functional teams, communication is easier, missunderstandings seldom. Colocation is a must and leads to much higher productivity. With one team there is only one responsibility. The team is tasked with a user story and the whole team is responsible for delivery.

Scrum strives for cross functional teams, the biggest hurdle for Scrum Masters on that road are political struggles and thinking in kingdoms.In Scrum, product owners (PO) and developers are considered one team, which is often not colocated. They belong to different departments with different goals. Therefor a ScrumMaster constantly needs to tell them they are one team. One real team makes Scrum easier and more successful. Companies should organize teams not at department boundaries, but value streams.

Team size

Team size is another paramter. From my experience, the team should be smaller than 10 people, team communication and managment gets more difficult when you approach the threshold of 10 people. Pete Abilla writes about the size of the famous 2-Pizza Teams at Amazon:

[…] Amazon’s 2-Pizza Team, which is defined as the following: a team where the team size is no larger than 2 pizzas can feed. Amazon realized early on that in order to cut software development time, the solution was *NOT* to put more people on the project.

The number of developers matters most, as it influences the number of the other team players. If the number is small, there might not be a good ratio to testers, designers and product managers. If the number of developers is larger, this is better, because it creates more throughput according to queuing theory. More throughput means shorter cycle time. Too many developers on the other hand lead to communication overhead and get ineffective says Jens:

Intra-project communication becomes more and more challenging with increasing team sizes. When team size increase so does the number of different communication channels. Every team member can communicate with every other team member. Mathematically it looks like this:
number of communication channels = n(n-1)/2, n=team size

While Jeff Sutherland goes farther and generally attributes lower productivity to large team sizes:

There is plenty of data to show that team sizes over 7 result in significantly lower productivity. Any team over 7 in size should be split up into multiple SCRUMs.


My dream team is a cross functional, cross department development team with less than 10 people. What would be your dream team?

5 Practices Better to Change in Your Scrum Implementation

Photo by royskeane

Scrum saw a big increase in adoption last year. Everyone who is doing Scrum, does it differently as Scrum is a framework, not a process. One needs to inspect and adapt, mostly through retrospectives and daily improvements. I’ve been an agile proponent since learning about XP in the 90s and had the chance to learn something about Scrum in the last years and positions.

It is hard to determine if someone is really doing Scrum, the famous Nokia test helps as a Litmus test. Jeff Sutherland writes:

In 2005, Certified Scrum Trainer Bas Vodde was coaching teams at Nokia Networks in Finland and developed the first Nokia test focused on Agile practices. He had hundreds of teams and wanted a simple way to determine if each team was doing the basics.

I’m certain Scrum needs to adapt. As I’m head of development at a startup, and a ScrumMaster, I had some canditates for a Java job and they’ve asked me about Scrum. I’ve told them we aren’t doing Scrum by the book. They’ve been suprised and thought we do Scrum-Butt:

Scrumbutt is a word for the organisations saying or at least thinking that they are using Scrum, but the fact is that they are only using parts of the method. It is when a user of Scrum is saying: “YES! We use SCRUM, BUT we have these deviations in our method…”

But there are two sides beside Scrum. Doing not enough Scrum – ScrumButt. And learning from Scrum and going beyond – especially more lean. I think we are more lean and beyond basic Scrum. How did I adapt Scrum?

1. No Review Meetings

Scrum has a review meeting at the end of each sprint to present the work done to all interested parties.

What we do: We have no review meetings. Reviews with customers/product owner are done right after a story is completed together with the developers.

Pro: Con:
  • Completed stories can go faster into testing
  • Completed stories can be deployed faster and go live earlier
  • It’s harder for other stakeholders to see the stories
  • It’s harder for the team to promote it’s work

2. No estimation of hours

Scrum estimates the hours remaining on each task card for each story. Those estimates are updated each daily scrum and drawn on a burndown chart.

What we do: We do not estimate hours.

Pro: Con:
  • Less work to do, so less time wasted on something which is – often – not needed, less waste
  • Updates of hours are done by one developer and therefor are more inaccurate
  • Harder to see if the time remaining in a sprint matches the work remaining
  • Developers are not bound by their hour estimates and tasks may take longer

3. No hour burn down chart

In Scrum remaining work in hours is drawn on a burn down chart.

What we do: We draw two graphs, story points remaining and tasks remaining

Pro: Con:
  • Less waste, as it’s easier to count SP and tasks than hours
  • Graph of tasks remaining shows if the sprint goal can be reached or if the team is behind
  • Story points remaining show that a team finishes stories too late in the sprint
  • Harder to see if the time remaining in a sprint matches the work remaining

4. We do not use Velocity for Sprint Planning

In Scrum some teams use the past velocity for planning the number of stories for the sprint.

What we do: We pull stories from the backlog. After each story was discussed during planning, the ScrumMaster asks the team if they can do this story in the next sprint. Go on until they say no.

Pro: Con:
  • Developers are not fixed on a number and therefor are more likely to improve
  • Velocity should increase in teams, if retrospektives are effective. So why focus exclusivly on past performance?
  • Because they are more aggressive with what they can do, developers may overestimate their abilities

5. We split the backlog into stories that are in planning and those that are ready for development

Scrum has a product backlog with stories and most of the time estimations. They are ordered top to bottom according to business value.

What we do: We add (at least) one more state. All stories which are ready for development are put in a “Ready” queue.

Pro: Con:
  • The team sees which stories are ready for development
  • The company sees if the ready queue is too large or grows too fast
  • More work for the ProductOwner, possible additional waste

I hope one or two things on the list get you thinking about your Scrum implementation and helps you to smooth your process and increase customer satisfication. What changes to Scrum have you applied? I would be interested to hear, please leave a comment.