BDD in Java with easyb (John Ferguson Smart)

John started out by arguing that TDD is not about testing, it's about writing better code. That is, it's about making your code more maintainable, flexible, reliable and simple. TDD is forces the programmer to think about how to test the class before actually writing the class. BDD, on the other hand, helps to determine what to test and to write more focused code, by starting with the behavior. Instead of thinking that you're testing your class, you should think that you're validating your requirements!

easyb is a BDD testing framework for Java, written in Groovy (hence providing full access to all Java API's). It ensures that tests become clearer and easier to both write and read! It helps the developer to focus on the requirements only. A competitor to easyb is JBehave, which is an extension to JUnit. However, according to John, JBehave is more cumbersome than easyb.

easyb makes use of stories, much like the story cards in the Agile world. In a story, a narrative approach is used to describe a precise requirement. In easyb, a story could look like this:

 
scenario “Make initial deposit onto a new account”, {
	given “a new account”
	when “an initial deposit is made”
	then “the balance should be equal to the amount deposited”
}
 

This scenario is quite clear and readable, isn't it!? Furthermore, it's self-documenting - a very appreciated feature =) And the syntax is so trivial that even a non-technical stakeholder would have no problem understanding it. The developer can then reuse the given scenario (pseudo) code and implement the test case, like this:

 
import com.mycompany.bankonline.domain.Account
 
scenario “Make initial deposit onto a new account”, {
	given “a new account”, {
		account = new Account()
	}
	when “an initial deposit is made”, {
		initialAmount = 100
		account.makeDeposit(initialAmount)
	}
	then “the balance should be equal to the amount deposited”, {
		account.balance.shouldBe initialAmount
	}
}
 

The shouldBe call is an intuitive and readable way to verify that the requirement holds. Another way to verify the outcomes is to use the ensure syntax. Example:

 
ensure(account.balance > 0)
 

or

 
ensure(account) {
	has([balance:100])
}
 

easyb could be extended to use DBUnit (and further plugins for Grails and Excel are on the way). On the IDE support, the only good option is IntelliJ IDEA. It really comes down to the Groovy support, and Eclipse and NetBeans doesn't shine here. In those cases, you're better off running the tests in Maven or Ant, which both are well supported. In the upcoming version, easyb will have full support for Continuous Integration (CI), enabling automatic test execution in a CI-server such as Hudson.

Furthermore, easyb comes with a web application - Easiness (cmp. Fitnesse) - where stakeholders can create stories in plain text. The developers can then go ahead and implement the stories defined by the stakeholders. This is an important features, that further improves the cooperation between the customer and the provider. It really seems like a quite nice little framework! If you agree, have a look at it at http://easyb.org/.

From Concurrent to Parallel – Library-based parallelism in JDK 7 (Brian Goetz)

Brian is an expert in the concurrency area, but he's not a good presenter! He speaks faster than I can read, and his slides are so packed with info that he doesn't have time to say the half of it. That put aside, in this very interesting session Brian presented some really cool concurrency features to be included in JDK 7.

As you probably know, JDK 5 introduced a set of very useful classes for course-grained parallelism. JDK 7 will introduce a framework for fine-grained parallelism - the "fork-join" framework.

We have now reach a point in time when Moore's laws isn't valid anymore. The new reality is not faster CPUs but more CPUs. To adapt to these changes, programmers have to change the way they think about parallelism. The unit of work (UoW) that represents a task to be solved must be split into even smaller parts to be able to keep all hardware busy. Nowadays, it isn't enough to for ex. spawn a new thread for each service call in a server, the UoW must be split up even further.

Examples of finer-grained parallelism is searching, sorting and filtering a data set. Such a task is preferably solved by dividing it into sub-problems and combining the sub-results at the end. We could use the course-grained concurrency tools (for ex. Executor + Future) introduced in JDK 5 to solve this problem. However, with multiple CPUs available, these tools doesn't perform optimally. For ex., the shared work queue in the Executor becomes a bottle neck when the number of threads/CPUs increases. Furthermore, these tools provide no form of load balancing, i.e. if one thread finishes before the others, it is never reused.

The divide-and-conquer algorithm could also be applied to solve the problem. This great advantage of this approach is that it's independent of the number of CPUs used! Using plain threads for this approach is too expensive though, since thread creation costs way too much. However, the fork-join-operation in JDK 7 solves problems like these using the divide-and-conquer algorithm in a much more effective way! Internally, it uses an slim thread pool to overcome the cost of thread creation. Furthermore, no data-copying penalty exist since the data set (for ex. an array) is not divided/copied during the solution. Instead, the indexes within the data structure is used to define each data subset. Another advantage is that the code doesn't know how many CPUs it executes on, hence it's portable!

While the Executor (JDK 5) should be used for tasks consisting of both IO and computing, the fork-join-operation (JDK 7) should be used for highly compute-intensive tasks. Examples of such tasks are matrix operations, numerical integrations and game playing. The JDK 7 class to be used for these kind of problems is ParallelArray. It's a utility class that greatly simplifies the work of solving a task in parallel. You can think of it as an in-memory database for data sets. Typical usage is:

 
ParallelLongArray pa = ParallelLongArray.createUsingHandoff(array, forkJoinPool);
long max = pa.max();
 

The ParallelArray class provides operations for:

• Filtering (nestable)
• Mapping
• Replacement
• Aggregation (max, count, sum, ...)
• Application (one action performed for each selected element)

To compare, the ParallelArray class acts much like the Map-Produce concept introduced by Google but it works in a different domain (local system instead of in a distributed system).

The only downside really is that JDK 7 isn't scheduled until mid 2010, meaning we'll have to wait quite some time before we can actually use these new concurrency features. But from the looks of it ... it may be worth the wait!

The SpringSource DM Server (Joris Kuipers)

The reasons why SpringSource decided to develop a new application server were many. Today, modularity is important and developers spend much time on achieving it in their applications (layering, separation of concerns, etc.). However, when the application is deployed, all modularity is lost - the deployable unit is one huge, monolithic WAR file. That means that sharing code (let alone services) between applications become hard if not impossible. In order to perform the smallest update on the application, whole WAR file have to be redeployed. Furthermore, the servers themselves lack modularity; they come prepackaged with a lot of modules but there's no way to configure that your application only make use of a couple of them. Hence, they are all left in there, consuming unnecessary CPU cycles and memory.

The DM (Dynamic Modules) server was developed to tackle these issues of non-modularity. In order to achieve true modularity, is has been built on top of OSGi (namely the Equinox container). Since OSGi can be quite hard sometimes, the DM server conceal the complexity of OSGi in the same way as the Spring framework does with for ex. Remoting or JMX.

In order to be able to use a third-party library from within the DM server (and from any other OSGi containers), the standard JAR library needs to be extended with OSGi-specific meta data - the OSGi manifest. SpringSource has therefore created the Enterprise Bundle Repository, where they have started to upload and publish OSGi-ified Java EE libraries. If you're using Maven or Ivy, the bundle repository can easily be configured as a remote (or local) repository.

The DM server also introduces a couple of new OSGi import constructs, enabling ease of development. One example is the "Import-library" that can be useful if you want to make use of a framework (for ex. Spring) but don't want to waste your time having to specify every single Import-package (for example Spring-Remoting) within the framework (as you normally would have had to do). This doesn't affect performance improvement since (thanks to OSGi) none of the pre-installed bundles are loaded before they are actually used! Furthermore, with the DM server it's now possible to remove the library bloat of monolithic Java EE WARs. Instead of building the external libraries into your WAR, you can instead declare them as dependencies in the OSGi manifest headers. The server will then convert these into plain "Import-package" constructs during deployment. That way, the size of the built/deployed WAR can be reduced significantly!

In the DM server, one can of course deploy plain OSGi bundles but also WARs, EARs etc. Typical scenarios for deploying a plain OSGi bundle are stand-alone libraries, global services and small stand-alone applications. However, being able to deploy a bundle is not enough in most cases ... A normal application normally consist of multiple bundles, which becomes hard to un/deploy since there is no single deployable unit. Furthermore, with multiple bundles you don't get a common log file or a notion of an application scope. To tackle this issue, the DM server adds the notion of an application by introducing the PAR (Platform Archive) format. It's basically a JAR with a number of 'Application-*' manifest headers. You can think of it as an EAR in Java EE. PARs are versioned and the versions apply to all of their bundles. This mean that one can deploy a PAR twice with different versions but with the same bundles, without conflicts.

The DM server comes in several versions. Of course there's the community version, using a GPL and SpringSource license. Then there's the commercial license where full support from SpringSource is included. On the extension side, better Maven support will soon be released so that the dependencies can be specified in a single place (not like now when you have to duplicate them in the pom and in the manifest). There's a Eclipse-plugin available that enables re/deployments from within the IDE.

These are some of the features in the DM server. There are plenty or more cool ones, read all about them here. There, you'll also find a lot of sample applications that can get you going! With the DM server, SpringSource feel that they are filling the (up until now) empty space of server side OSGi and states that "The DM server is the healthy new way to run your apps!". I must say it looks very promising! Why don't you go ahead and try it out!? I know I will!

If you appreciated these posts, you will definitely enjoy next years conference! Pick up your calendar and reserve December 2009 for a great week at Devoxx!

The first part of this series can be found here: Scrum Shock Therapy, Part 1.

The Management Recipe

The checklist above is only a part of what it takes to go through Shock Therapy. I often find myself at new companies and need to work with a bigger picture than focusing solely on the team. As is evident from the polls and surveys above, we need to address management as well. The word shock is perhaps more applicable here. If it has learnt anything from the past it is that you have to "drive" development - delegate, follow up, check, adjust, hand out, recheck...
Telling them to trust the very group that has not delivered before is asking for a leap of faith.

Setting up a recipe for this group is tricky. You have to adapt to management style, the corporate culture and so forth and the things you ask for are softer. These can be very hard indeed to change! In plain English; The management has to take some more real tough decisions for a Scrum to work efficiently. If you need to kill a document standard or process step then do so! If this is impossible (for now) then go for "barely enough".

The Management

• Attend the Scrum training session with everyone else
• Hands off during 3 iterations
• Attend:
• Some Daily Scrums - be quiet
• All Sprint Reviews
• Start to work on waste - now!
• Management by walking, asking and listening, i.e. practice facilitation.
• Make the first step easy for the team
• ...

When learning something new you have to do it several times just to make sure you are not totally confused. I have found that three times a charm. Try your best to get management to abide by this "rule". After the three iterations everyone has better picture to judge the value of the effort and Scrum.
Eliminating waste is vital on any type of project or endeavor. In a transition it makes even more sense, you have to make space to learn something new.

Finally, management has to ask the people that will perform these miracles what they need to do just this. Have they? Have you?

The Management Exit

• One successful team
• Removed impediments and studied results
• Change in perception at "ground level"
• A good agile reason to change the rule

Having one successful team is sort of self-evident. This takes patience when the ride is anything but smooth. Being a part of this process is important. Management will have the best ability to change ambition level, removing impediments etc. Get cracking and be that good example.

If there is a change at ground level on how they perceive management, then you're probably on to something.

Is this recipe the final version - probably not? Your mileage will vary, adapt to your management.

The Organization Recipe

Many of our customers are just starting out doing Scrum. Therefore we typically come into play as an external effect. It is important for us to understand how the agile effort has started and its nature within our client's organization. We can basically divide this efforts into to two major types - "bottom-up" and "top-down". The typical traits for a bottom-up style is one where the programmers et al have decided to go agile. The management might be aware of this and even letting it run. Then again this might be a stealth and an under the cover job.

I have found the bottom-up approach to be the most common case. Programmers usually like to work in an agile way. In these type of setups my work usually revolves around questions like "How do we fit this to a waterfall context?" etcetera. This can be tough work, but I find it to be the more easy of the two - the people who do the day to day grinding are already on board.

The top-down effort of introducing Scrum comes with its own set of problems. Any methodology or decision that involves change tend to meet resistance from the organization. We need both experience and sideways effort to the transition.

The Top-Down Scrum Organization

• Get a Scrum Sensei
• Inject a Agile Senior Programmer into the teams
• Make sure there is organizational transparency

The Scrum Sensei is an experienced Scrum Master who's been there before. Much in agile and Scrum is common sense, but there is no need in making the simple mistakes. With a battle-trained mentor the whole organization get a sounding board (Swedish: bollplank) helping out to implement Scrum. This part is important to the Shock Therapy where he or she will be the contract owner enforcing the startup and approving exit. In some sense this person could act as a "bad cop" in a good-bad ScrumMaster setup.

Or in the words of Nanny McPhee - a children's movie where a nanny answers the seven ne'er-do-well children on how long she will stay:
- When you need me, but do not want me, then I will stay. When you want me, but do not need me, then I have to go.
The Scrum Sensei needs to work in similar way to bootstrap the team and management.

A top-down effort always risks resistance from the organization. My experience tells me that a side way force is needed for translation on the factory floor. Moreover, such a person has the experience on a technical level to do the hands on tools and practices that is a vital part of any agile projects. A seasoned programmer with agile experience knows what works and how to translate the management vision into bits and bytes.

"Self-evident" sometimes reads "evident to myself and no one else". If we want to affect the organization we also have to make sure that practices, experiences and results are easy to come by. Walking down a corridor should yield interesting information about ongoing projects. If there is a pilot project doing Scrum then visibility is high on the wish list. Not only does it mean commitment for the Scrum team, but also a pull factor for other teams to get on board. Organizational transparency comes in many flavors. Apply liberally!

Summing it up

There is no denying that projects have problems getting started with Scrum. But more often than not I believe that we can do something about it. Why not try some nice Shock Therapy?
It might be the sweetest hard deal around!

/Björn Granvik, Jayway

MySpace Therapy:
http://jeffsutherland.com/scrum/2008/09/shock-therapy-bootstrapping.html

Scrum Poll on Nokia Test Practice:
http://tinyurl.com/68vapj

VersionOne Report: State of Agile Development Survey:
http://www.versionone.com/agilesurvey/

Situational Leadership:
http://en.wikipedia.org/wiki/Situational_leadership_theory

Nanny McPhee:
http://www.imdb.com/title/tt0396752/

I asked for comments/questions. As it turns out I got mostly questions on Scrum in general and not so much on my topic - how to bootstrap Scrum. I'm not sure what to make of this.
Anyway, here are my takes on those questions. I hope they're of some value.

Dear Björn,

How do you motivate a team to produce more without paying more for IT (salaries)?
Hourly salary seems retarded for agile teams.
Thanks!

Dear anonymous,

I'll first look at the non-monetary part, mostly Scrum, and later on salaries and bonuses.

Self organizing
In many organizations people enjoy very limited control over their own situation. Being able to self organize is important. We humans just tend to like this.

Pick your tasks and choose your implementation
Again, if I can use my competence and decide (as far as possible) on how to implement a certain goal, I will enjoy my work the more. Using this approach I've even been able to rehire people to very problematic situations. Very powerful.

Deliver
When I ask programmers what they are most proud of, I usually hear words like "idea, made by me, real users". It might not be the hardest and certainly not the biggest project they worked on. They used their competence, created something and delivered! In Scrum you get the delivery feeling at every sprint. If you break it down into activities no bigger than a day, then you will get that nice "flow" and people will be able to say "I did" every morning.

Good Colleagues
I've found that Agile makes sense if for no other reason than you can keep and hire the good people. SmartFriends(tm) is a great way to work!

I'm sure I could pick more facets of Scrum and Agile on how to motivate your team. But let's move on to the Money. This part of my answer doesn't have so much to do with Scrum or Agile, but rather my beliefs. So you have to be the judge here - what would work for you and your situation?

Powerful, way too powerful
Salaries, bonuses etc affect you - all the way to the bank and your holiday and...
In short: Once you start using money in different forms as your primary means of rewards, you will get a powerful ally in driving your people. Perhaps to powerful.

Take bonuses at a consultancy firm (a real example from life). You have all the good intentions so you set up a bonus system so that everyone will benefit if they have a client. More hours with customers, bigger bonus. Easy. This way you can lower your costs in bad times. Nice, if you're just counting beans.

Effect: No one wants to come in do monthly meetings if it's going to cost them money.
Counter effect: Introduce a threshold so that there is room for a bonus even though it doesn't mean 100% with customer.

Another effect: You just removed your ability to make strategic decisions like "put someone on the big corporate account" that pays less, but means more hours. Who wants to loose money working for that customer if they have to take a cut money-wise?
Counter effect: You introduce another "rule" specifying that a lower price per hour will not affect their bonus.

Yet another effect: Holidays suddenly never cross the monthly boundaries. That would put your people below the threshold for the bonus on two separate salaries.
Counter effect: ...haven’t got the faintest here what they did here.

I hope my example makes sense in your situation. My point is that money matters. When used to drive people you will get side-effects.
For me this is not good enough. I don't want just to persuade people's wallets - I want their hearts and minds. It has to be fun and engaging.

Here's my short take: First make sure you have decent salaries etc. When this in place, aim for those things that make our working day worth while. Set interesting goals, get good colleagues, the right work to do, empower people and so on.

How to ensure creativity and quality in Scrum?
/Fredrik

Hi Fredrik,
I liked the way you wrote this on a green note (meaning "good" when voting at the conference). Thanks

Creativity
I believe there doesn't have to be a contradiction between setting a goal and using proper frames (time, resources etc) vs. creativity - at least as long as we have the right to work to our own judgement within these constraints. I often find that this last part is missing. You get all the obligations, but no mandate.

In Scrum, one part of the creativity is built right into the process: Understanding the different goals. In the product backlog you should enter business value. This way the team has direct contact with the user's intentions and can suggest alternative solutions that might be better, i.e. be creative.

Quality
If we're talking IT, I would like to use automatic testing, continuous integration and so on to ensure consistent quality. Add to this an annoying email whenever something breaks and you have a good start

Moreover, the tight feedback loop using sprint reviews and such should pick up on issues like usability etc. Basically make sure you have a product owner that can spend time on the project.

Also make sure that your "definition of done" reflects your quality goals. It has to be very clear what "done" means within your organisation.

Hur gör man för att bryta ner gigantiska projekt över flera plattformar i lagom stora bitar för att köra Scrum?
[How to break down into gigantic projects over several platforms into decent chunks so that Scrum can be used.]
Sven Nilsson, SAAB

Hi Sven,

Your question seems to revolve around two hefty issues: Breaking down the project into several teams that are likely to depend on each others and breaking down the actual work to fit into a sprint. Perhaps "platform" has a special meaning within your organization and how you work. I would have to know a bit more to answer you on that point.

Teams and dependencies
This is tough on several levels. First let's do the pure Scrum answer - Scrum of Scrums. This basically means that we organize our teams so that one person from each group "steps up" and forms a team that work across several teams. Dependencies etc can be resolved in this group, set up an encompassing backlog and work much in the same fashion as a Scrum Team. Jeff Sutherland, co-fonder of Scrum, has run this set up on 500+ persons. I would love to work on such an outfit.

However, and this is a big however, this is a major change for most companies. The ones I've met (medium size and up) just aren't geared to handle such an approach right now. The number of issues and obstacles with such a transformation can be huge. If you find yourself in such a situation then I suggest you adapt piece by piece and continuously strive to be ever more agile. This is hard work and will mean small improvements upon each other, but maybe no hyper productive state.

This is where I chicken out and suggest you should get someone with experience. Every company is different and needs their set of actions.
Hell, buy me lunch and maybe I can point you in a good direction

Breaking up the work into chunks
This takes creativity.

First: Try to slice the work so that you will touch base with most layers/parts. This way we can have a better understanding of what it means to deliver the whole system. Therefore make the slice as thin as you can while at the same time deliver something "valuable". This might mean you need to mock other components (code that isolates different components with dummy answers). This can be very beneficial since it becomes some sort of contract with other teams.

If the chunk still is to big then you might have to resort to cutting up the chunk into parts by level in your architecture. This of course has the drawback that we don't know what it will take to implement the parts we didn't do. Business value might be less, but we might be able to "prove" that we're on the right track. What is "proof" to your product owner?
If you can, stay away of doing tasks in your product backlog. In worst case people will be task-driven: "I've changed the registry, can I go home now?"

If we want to/have to promise the customer a delivery date. How can we do that when we don't analyse the whole project?
We are focusing on the next sprint?

How can we tell management how many resources we will need in one month?
/Patrik Johansson, Ericsson

Hi Patrik,

Several questions and perhaps the most common ones. Let's dive into them.

Analyze the whole project?
Why we can't analyze the whole project? Because, this is blatant lie for anything bigger than a trivial project. I apologize for my frankness, but I've never seen a project with a single version of the Gantt schema, a single time plan, with a known set of resources...
They always change. Always.

If you and your management can't agree that things change then you might have to go dualistic - outwards project manager old style, inwards ScrumMaster. It's not easy, but in time you will gain some victories, err deliveries, and you can move the agile thinking further up. Hard work, but it's better than doing waterfall all the way.

Your question is still valid. How do we commit on delivery if most things might change? The customer still needs to plan an ad campaign.
One trick is to reinterpret the "commit to delivery date" into agile terms. Get a stable backlog and learn the team's velocities. This way you can commit to the same "distance". Things will change, but (as always) it's down to making things fit into the available time.

For this work we need some iterations under our belt to know our velocity and hashing out what the product backlog should contain. Therefore, mix the project plan's you have do at the start with some "real work" like coding. Inspect and adapt. After while I think you will able to commit to management.

Focus on the next sprint?
You shouldn't just focus on the next sprint. The closest work (sprint) is fine grained and the most well understood. The further away (further down on the product backlog), the more coarse grained should the user stories be. No point in being specific, when they're far into the future.

Resources?
Which resources can you get? Go for full time members. Make sure can keep them. Look at the product backlog and calculate what you can get done with the people (velocity etc) that you got. The important part is to couple the resources with the goals. All too often your resources get slashed and the goal knocked into orbit - and not on the same day.
Get them in synch so that a change in one of them will affect the other.

I hope this helped.

Regards,
Björn

I'd love to get your feedback. See you in the halls and the Way Group booth.
Or you can just give your comments about the session here on this blog.

Developer's conference in Malmö, Sweden

Scrum and Agile development has started to rock the world within IT in various ways. A simple, but powerful process that seems to deliver. Developers and customer alike are happy. What's not to like about it? Still, there are signs of problems. Projects that claim to use Scrum do not reap the benefits, management looses patience with this new method and team members struggle to adapt an agile approach to their everyday work life. Why is this? And more importantly, what can we do about it?

The Therapy: Get off to a good start by directing the team with a careful set of good practices and a strict agreement that leaves little or no choice. The team can then, over a couple of iterations, gradually take command themselves.

Easy, but still so hard

Why then is Scrum so hard? Well, first of all it is fail-fast, meaning that any problems will be quickly apparent. There are no artifacts or process steps to hide behind. This is never easy. To this list we can add even more pitfalls that are just plain hard to deal with whatever method we are using.

Still, it does not explain why there seems to be so many simple mistakes with such a simple framework. One of the best examples is the failure to keep backlog that is prioritized and up to date.
- We're doing Scrum, but we're too busy to work on the product backlog!

That one has always short-circuited my brain. What can be more important than to decide what is important? This pattern of falling short and missing basic parts of Scrum even has a name - "ScrumButt". If you look in the sentence above you see why.

Nokia created a test to make sure the projects are "Scrum enough". These plain questions form a lithmus test that can be used to analyze most agile projects.

The Nokia Test
Iterative Development?

• Iterations - time boxed, less than 4 weeks.
• Software features - tested and working at the end of each iteration.
• Iteration must start before specification is complete.

Scrum (in Nokia's opinion)?

• You know who the product owner is.
• There is a product backlog prioritized by business value.
• The product backlog has estimates created by the team.
• The team generates burndown charts and knows their velocity.
• No project managers (or anyone else) disrupting the work of the team.

The questions seem to be on the easy side. It turns out that this might not be the case.
One online poll, Nokia Test by Practice , about the ability to achieve the Nokia Test level gave some interesting answers. In essence, only one out of four give themselves a full mark. Half of the groups report that management interferes, not directs but interferes.

Informal queries by Jeff Sutherland among his audiences around the world give an even worse number - something like 1 out of 10 pass the Nokia Test. Hand on your heart: Does your project live up to this?

A survey by VersionOne tries to dig deeper into the current state of the Agile affairs. Under the headline "Top barriers to adopting Agile" we read the top four answers:

1. Organisational culture, 45%
2. General resistance to change, 44%
3. Lack of people with experience, 42%
4. Lack of management support, 32%

Take a long look at these barriers. No technical stuff. Nothing specific to agile. Just people.

What do we know?

Learn to walk before you run. Greek Proverb.

We could be a bit closer to today's reality than these ancient words of wisdom. The Situational Leadership offers an approach to management that has been around since the 60's. These theories say that there is no single leadership style that is optimal for all people in every situation. Situational leadership talks about four different leadership styles that need to be matched with the follower. Basically, when leading someone who is passionate, but have no experience, you should adapt and give clear directives. As the follower evolves his or her ability to execute, so should the leader using less directives and more encouragement. In the end the follower is able to perform with only a stated goal and little or no directives.

If this holds true for people, could it not be true for teams as well?

The Shock

So we have problems making Scrum and Agile efforts to run. What is the conclusion? Could it be that we adapt our leadership style to the group? Make them walk before running?

This is counter intuitive, at least to me: To go agile, we first need to control. We should not let our teams and managements start off without some kind of directives. Give them a good deal, some practices that make Scrum work. Otherwise, we are just repeating the same old mistakes as the next-door agile project. Set up an agreement with both management and team so that they can evolve and experience Scrum for real. Just reading a book (or article) or listening to some good speaker alone does not help you out there in real life. You have to experience it.

Shocking as it may feel: We need to exercise some control over the Scrum project start so that it can evolve and self organize! But, and this is a big but, this has to be done with compassion and genuine involvement, otherwise we stand the risk of destroying what we are trying to build.

The Therapy

So what can we do? We need to work the team, management and often the whole organization.

The Team Recipe

So how do we get started? Here's a recipe for the team as it used at MySpace:
The Team

• Scrum training session for everyone
• Sprint 1 week long
• Definition of Done:
• Feature Complete
• Code Complete
• No known defects
• Approved by the Product Owner
• Production Ready
• Story Points
• Physical Task Board
• All-in-one Sprint planning meeting.
• No Multi-tasking, work in priority order.

Scott Downey, Agile Coach at MySpace

The idea of this recipe is to set a good practice right from the start. Instead of debating the details on how to work in an agile way, we can focus on getting going.

Everyone has to have a common Scrum understanding to start from, hence the training session. One-week iteration sounds really tight for any reasonably sized projects. The thinking behind this is to get as quick iterations as possible - the faster that the group gets going the better. Short sprints help in this aspect. We learn faster with more turnarounds.
This in turn affects the meetings where MySpace has elected to combine them all, except the morning meeting, into one single occasion. The time is just too short to in a weekly sprint.

MySpace's definition of done is a good and basic list. However, as a programmer I lack for instance continuous integration, pair programming and so on. These are not mandatory to have, but I see them as enablers for Scrum and supporting your agile initiative.

The next two on the list - Story Points and Physical Task Board - are really effective. If you haven't tried them out then please do. They work. Finally we have something that is a no-brainer to me even though I have great problems avoiding it, "No Multi-tasking, work in priority order". Context-switching is expensive, just avoid it. The priorities are in order, you just have to follow them. In the Reference box you find a link to Scott Downey's description of their therapy.

When the team matures, they should evolve and handle things more on their own and no longer need directives. At MySpace the group can "prove" that they are ready for prime time by reaching the following goals.

The Team Exit

• Hyper-Productive (>240%)
• Three successful Sprints consecutively
• Good business reason to change the rule

The Result?

So how does this work out? At MySpace all groups achieved exit. All, but one, improved after that. One group even achieved a whopping 1,650% improvement after just four months (16 sprints). At Jayway one of the teams used such a bootstrap technique, primarily on the technical side, and reached 800% after 3 months.

The second part of this blog can be found here: Scrum Shock Therapy, Part 2 where I will look into how to handle management and organisation with some recipes.

/Björn Granvik, Jayway

Jayway will in cooperation with Sambruk develop a new platform for workflow management called Streamflow. During my years of working with the Swedish government with my earlier product company Senselogic I have come to understand that workflow really is the core of what the Swedish government departments are doing, and that their current attempts at using workflow software to automate some of the work is failing miserably. I mean totally and utterly miserably.

Because of this, and many other reasons, we now want to attempt to build a workflow product that is more adapted to their needs, and can help them adopt an agile mindset in how they approach their work. This involves being able to constantly monitor their processes, how they are working (or not), and get things done more efficiently. But most importantly, the main focus is on getting each individual in the organization as efficient as possible, and this is helped by having tools to manage the overall structure of how information and issues flow through the system.

The entire platform is going to be a commercial product, but it will be using the Apache 2.0 OpenSource license. This means that anyone will be able to download and use it for free, and we will offer support subscriptions for those who want that. We hope that lots of people will find it useful not only in their work environment, but also for private use. On the surface it is going to look like a Getting Things Done application, although underneath there will be tons of places for integration with existing systems. This we hope will be a good solution both for individuals and organizations.

In terms of technology it is going to be based on everything I've learned from my work on SiteVision, and the latest developments in terms of SOA principles. It will be built upon Qi4j for the domain logic, and use REST as one of the core integration points. While this system will be built in Java we hope that others will create extension and plugins in whatever language they want, with REST as the way to communicate with it.

The article mentioned above has a number of questions in the comments section, so I figured I would also try to answer some of them here.
Q: It would be good to be able to monitor the entire flow of issues in the system
A: One of the key requirements in building a new workflow system is that citizens need to be able to track the status of their own issues through the web. This will be built-in from the start.

Q: It should be possible for citizens to comment on how they feel the processes are working (or not-working) so as to be able to improve them-
A: Continuous improvement of the processes is going to be a big goal here. The mindset we want to adopt is very similar to Scrum, and process models should be iteratively improved as new understanding of how to achieve the goals is gained.

Q: It would be nice if the system was based on portlets for easy integration
A: The system itself will be a standalone server, but will have JSR168 portlets for integrating it with the current portal servers that the municipalities already have, such as SiteVision

That's it for now. There's a whole bunch of more things to describe with regard to this project, but one step at a time. Right now I'm just really excited about the response I have received so far when talking to both developers and government officials about these ideas, and it is obviously something that many people care about it.