As we do agile software development for our customers I was curious what agile enterprise means. So I asked Google and read some articles about it. A good definition can be found at the Business Dictionary:

Fast moving, flexible and robust firm capable of rapid response to unexpected challenges, events, and opportunities. Built on policies and processes that facilitate speed and change, it aims to achieve continuous competitive advantage in serving its customers. Agile enterprises use diffused authority and flat organizational structure to speed up information flows among different departments, and develop close, trust-based relationships with their customers and suppliers.

Basicly “Agile Enterprise” means that enterprises are forced to change quicker and be more flexible as globalization has changed the way our markets work. Most of the articles I’ve found suggested to use self-organized teams and high interaction between people in an organization. But what does this mean for IT?

Let’s get back to the article. The article is about big ERP systems and about the problems most of the customers have with these systems if raising flexibility and speed of the business hits the IT. The reasons for these problems can be found in the high complexity of these systems, low productivity in development as a result of excessive customizing of the “standard” system. The statement of the article is: “ERP slows business down!”

Most of the arguements in the article are understandable for me and we see them every day in our projects. But not only with ERP systems, but with any kind of big standard software “monsters” – e.g. big insurance core systems. I have always asked myself why people first spend millions for licences and then realize that the “standard” doesn’t fit to their needs and processes. In many cases this leads to big customizing projects that run for some years and change the “standard” so much that you cannot upgrade to newer releases anymore. So every upgrade will be another midsize project. But I still forgot to tell you the best of the story: You pay 20% per year for support of the standard software – which means that you pay the intial millions again -  every 5 years!

Unfortunately the article doesn’t give good advices how to solve these issues. The strategy of the big ERP vendors is criticized – especially that the promices of SOA were not fullfilled.

A possible solution is seen in the cloud or in Software as a Service. This realy irritated me. So if I don’t operate the standard “monster” myself and put it in the cloud all my business problems are solved and the IT is flexible and fast enough to keep the new pace!? The statements of the many experts of big consultancy companies really scared me…

Last week I’ve thought a lot about the  “Why” for our “Agile Software Factory” and this article and the statements of the experts really helped me to find it.

For me the solution is obvious:

If “Agile Enterprise” means that the business has to be innovative  (First Mover) and fast adopting (Fast Follower), than the solution cannot be a standard software. Because “standard” definitly is the opposite of innovation and the monolithic character of the software often means complexity and not flexibility.

In my point of view we should implement the business processes with individual software. The used components can be standard and I don’t want to tell you to write a booking system from scratch. There are many laws etc. that regulate a booking system so that there is no room for real innovation. But the processes around the booking system can be very specific to the business of a company and putting the processes into the internet and offer customers and partners direct access to it could be a competetive advantage. Also a tight integration in other systems can offer more productivity. Wouldn’t it be great to offer one clean and easy to use interface for all applications and processes to the business users?

If software development should be faster and more flexible and the requirments are not fully known at the beginning of a project as we have to deal with a quickly changing business, you have to use a methodology that minimizes the risk of individual software development. Agile software development offers you the needed methodology. We will not be able to deliver business value quickly with waterfall approaches and projects that run for months or years.

And this is exactly why we offer the Agile Software Factory: A proven approach based on Scrum and XP to develop individual software. With years of experience and lots of best practices we can develop software fast and with high quality. We call it a “factory” because we use standardized components and frameworks for our development and do not reinvent the wheel for every new customer.

We use Open Source components as they offer open standards and open sources. This helps us to build software that is very extendable and easy to integrate in the systems of our customers. In addition to that we are not encountered by the politics of the big vendors. Alfresco for ECM, Pentaho for Business Intelligence, Liferay for portal, OpenCms for CMS  or Compiere for ERP and CRM are only examples of stable mainstream Open Source components. The individual processes and applications we develop for our customers are based on a lightweight architecture and well known Open Source frameworks like Spring, Hibernate, Drools, jBpm or Mule.

Our agile process gives us the flexibility to deliver running software to the business very 2-4 weeks! So they have new needed functionality very fast and in high quality. This quality is enforced by automated unit-, regression- and system tests, continuous integration, pair programming and automated code- and design reviews.

If this isn’t what “Agile Enterprises” need – we will move to the cloud

In connection with “Scrum”, the role of the project manager does not exist any longer. Most of the capacities and responsibilities have been distributed to the three roles “product owner”, “scrum master” and “team”. How does this happen regarding the composition of the team? The following subtasks have to be considered:

• initial team composition
• missing skills within the team
• enlargement of the team (in order to increase velocity)
• diminishment of the team
• indentify and exclude “low performers” and “troublemakers”

Initial team composition

The composition of the team at the project’s start can not be made by the team itself because it does not exist at this time. By means of his budget responsibility the product owner of course has a very strong influence, but the detailed decision certainly lies with the scrum master. He shall pay attention that the team works, especially in the beginning, both related to the professional and the social skills of the team members.

I think it is a fascinating question, how a good composition of the project team during the whole course of the project would look like. However, dealing with this question would go beyond the scope. I am going to illuminate this topic in a future article.

Missing skills

Should the team lack skills, which are important for the project, this will be regarded as an impediment very soon. Mostly, this will happen in the daily scrums already, but latest in the retrospectives. Then it will be the task of the scrum master to fit the team with the missing skills. The scrum master has different options:

• changing the composition of the team
• training / coaching of team members
• access to specialists outside the team

Enlargement of the team

The decision is to enlarge the team to increase the velocity in the long run. The reason for this can be a decreasing (or stagnating) velocity, an increasing deadline pressure from the outside or simply free full-time equivalents, which shall be integrated in current projects.

In the first place, this case occupies the product owner and the team. The product owner always has to trade an increasing velocity against the higher costs (caused by the larger team). On the other side, the team is able to judge, to which extent further team members would reasonably help.

Diminishment of the team

In the project business, there is “idling” from time to time. The reasons are very different, for example, all further tasks are dependant on a specialist task, so that they are blocked. At the sprint end, the sprint-backlog is empty or even the project end is characterized by an empty product-backlog. Moreover, in most cases projects only allow a limited parallelization. This can vary in the course of a project and in this way it can cause “idling”. The “idling” can be a spontaneous phenomenon, or it is of systematic nature.

The first task is to recognize that there is a systematic “idling”. This is the turn of the team and scrum master. Then, a suitable solution has to be found, preferably (and in most cases, this is also possible) in the current team, for example by reshaping of the tasks, in order to by-pass the specialist shortage.

But especially when the end of a project is near or a high parallelization, which has been used so far, is not applicable, it makes sense to diminish a large team.

Maybe the team can decide, which new team size would be suitable, but I think it is not clear, who will define the team members, who have to leave, and in which way.

Low Performers and troublemakers

In my view, one of the more difficult tasks in the project management is dealing with team members, who do not show the required proficiency level or who disturb the teamwork vehemently and constantly. One advantage of scrum can be the self regulation within the group. However this would require according social skills and a good standing of the other team members. But you can not assume that this alone is going to save the situation. Then it is the turn of the scrum master to recognize such things, to bring them up and to press for a solution. In such situations, the last resort will be to exclude the according team member, but it is not clear, who will be allowed to make this (very hard and final) decision.

Conclusion

Also in this area the tasks are divided to the new roles. Especially for difficult decisions, but also in the initial phase of projects, the “conventional project leader” can be missed despite it all.

Dr. Ingo Schrewe from incowia GmbH and I wrote an article how agility can help to reduce risk and optimise the results when implementing an EAM. The article was published within the scope of an EAM online special by SIGS-DATACOM and can be downloaded here: http://www.sigs.de/publications/os/2010/EAM/friedrichsen_schrewe_OS_EAM_10.pdf (available in german language only)

Ingo Schrewe and I plan to continue this article by writing some more articles that provide practical guidelines, hints and examples how to establish an agile EAM … whenever we will find the time to write those articles …

Now, here at codecentric we know a quite different story. Practicing agility for quite a while we had the opportunity to be part of the first agile projects that some of our customers implemented. Most of the times those customers had a tough deadline to meet or something similar that would not work with their standard processes and they had heard about the speed of agility. And, to make a long story short: At some point in time we were there to implement the project in an agile fashion. But throughout the implementation of those projects our observations were often quite different than you would expect it from the “common story”:

The business departments simply *loved* agility! They were happy that they had fast feedback cycles and somebody who was going to have a real communication with them, not just urging them to write another formal document whenever they had a problem or a requirement. They loved to see their vision growing in short iterations and having the opportunity to fine-tune their own ideas. They even loved to figure out where they were wrong with their initial ideas because they had the opportunity to change it easily and to improve the final product a lot that way. They were simply happy and they never wanted to do a non-agile project again if they had the choice.

The management also was quite fond of agility. The business management liked it because their departments loved it and the IT management liked it because the business management stopped complaining, about delivering too slow, putting too much workload on their folks, and so on. Okay, with the IT management it wasn’t always love on first sight. They often were quite suspicious about that agile stuff because they had no idea what it would mean for them if that would really become a big success. Sometimes those managers secret hope was that this agile project would fail. Then they would have shown to the business folks that all this agile stuff does not work out either and that they can stick to the way they did it before. On the other hand, when the agile project turned out to be successful they liked the part that the business people were quite happy.

And then there were the developers, those guys from the customers IT department who should be lucky that finally they are allowed to work agile, after all those years, shouldn’t they? Surprisingly, most of them weren’t lucky at all! They liked their processes and artefacts very much and most of the time they were pushing towards “more formalism”. They felt save in the world that they built up throughout the last years. Whenever something went wrong in the former years they added another piece of formalism, another process step, another artefact. They had built their own comfortable world within the bounds of their processes. Everything had its place and its order. Everything was defined in their processes and things that were not described in their processes simply were not allowed. And the best part of it: No one had to take over real responsibility for any failure. As long as you comply with the processes you have done everything right and if something goes wrong it must be the fault of someone else. So, simply do whatever the process tells you and you are safe! Whew, what a relief!

You can imagine that agility with its focus on the product instead of the process, with self empowered teams who take over responsibility for the result, with its enforcement to communicate with business people to clarify things instead of simply rejecting specifications, this whole strange agile thing wasn’t exactly the thing those developers were looking for. It actually scared the shit out of them! It made them feel really uncomfortable. They did not know how to deal with this and they always had that creepy feeling that they could be responsible if something would go wrong. No, they weren’t lucky at all!

Yes, I exaggerated it a bit to make the point plain, but: That is not a problem of some particular customers of ours. That is something that you can find throughout the whole industry and we had a lot of talk and discussions with many other agile protagonists who approved that observation we made. And it is not that those developers don’t like agility because they are “evil” or “backward” or whatever. They are simply insecure. They built their well organised comfort zone for many years or they were forced into that comfort zone and they simply haven’t learned yet how to deal with this agile way.

And what is the moral of the story? Yes, it takes a lot of change management efforts to introduce agility successfully into a company, but … *but* quite often it is not the business departments that we have to prepare for agility; it is the IT departments that we have to prepare for agility. Strange, isn’t it? …

A short “disclaimer”: I am not talking about *all* developers. I know many of you have an agile mindset and really love to work the agile way. But on the other hand there is still that huge mass of developers around who do not want to become agile or at least do not know how to change, and I think it is those people we have to focus our change efforts on, not on the business folks.

In 2001 Andrew Hunt and David Thomas introduced a benchmark for modern developers with their book „The Pragmatic Programmer“. The focus of their work is on practises, tools and design-paradigms to help programmers produce better code.

In my point of view being a “Pragmatic Programmer” is not enough for the challenges of agile projects. This blog entry takes a closer look at the developer in the team of a Scrum project. I explicitly distinguish between “programmer” and developer” because the word programmer tends to focus more on coding and less on all the other activities needed for implementing an application. (e.g. testing)

According to Ken Schwaber (who formulated the inital version of Scrum together with Jeff Sutherland), Scrum was mainly inspired by an article of the Harvard Business Journal that was published in January 1986: „The New New Product Development Game“. The article analyzed the criterias of successful new product developments of companies like Honda and IBM. One of the main assumptions of this article for successful product development is:

„Stop playing the relay race – play rugby“.

For software development this would mean that the old sequential approach (aka: waterfall) doesn’t work anymore and we should start using a holistic approach.

Scrum has taken the basic characteristics of successful product development teams like self-organizing project team, overlapping development phases and subtle control and integrated them into the Scrum process. Scrum combines them with ideas of iterative, incremental development and lean principles.The Scrum Alliance provides training and certification for Scrum Master and Product Owner – but why not for the developer? Does’t the success of a project mainly depend on the team? Are there any implications on the skills of a developer by changing the work model to self-organization with overlapping development phases or by delivering high-quality software every 2-4 weeks?

My personal opinion is that agile methodologies like Scrum fundamentally change the way developers work. Therefore new skills and attitudes are required.

Let’s start by looking at one of the most important changes in agile projects: self-organizing project teams. Self-organizing means that there is no “command-and-control” paradigm anymore, where (project) managers tell the developers which work in which time sequence should be implemented. Self-organizing often sounds like stress-less freedom for the team – but often turns out to be a very tough job.

The team takes the responsibility for delivering high quality software in time by committing to the Sprint goals. This implies that team members have to discuss, solve conflicts, organize work, estimate effort, pull needed information and commit to team goals. In “classic” projects this is done by defined roles like project managers and in many cases developers have no experience how to deal with these challenges. The success of agile projects depends on good self-organization teams – I’ve seen managers quickly return to “command-and-control” if this doesn’t work out as expected. So in my point of view organizations have to provide developers with training and coaching to get the needed social skills. Today I see that these kind of trainings and coaching are only provided to management and leadership positions. By inverting “command and control” we also have to rethink the training strategy for skills like team building, coaching, training, negotiating, decision making, problem solving, active listening and discussing/debating – our developers will need them to organize themselves in an agile team.

It could be also useful to provide trainings to help team members understand the strengths and weaknesses of their colleagues to support the team building – methodologies like Team Management System and DISC can help teams to improve.

When we started with agility at codecentric we quickly found out that we had to train not only technologies and tools but also these kind of social skills, if we want to improve our customer satisfaction even more. So we hired an external trainer and coach to develop a social skill program for our developers to sustainable improve their skills in that area – the feedback of the participants is great and we see a lot of improvement in the teams.

The second new paradigm you get with Scrum is: overlapping development phases – like self-organizing this requires new ways of thinking for developers. In the classical, sequential process models, all the requirements are documented by writing detailed specs, filling out use-case templates and provide UML diagrams which exactly describe the whole system (ok, I am a little polemic). With these specs in place the developer could start coding and if he was a good developer, he tested his code. But he shouldn’t bother too much with testing as the next team in the process would do this for him: quality assurance.

In agile projects these strict constraints are disposed and the responsibilities of a developer are widened. In my point of view developers will have to deal a lot with defining and talking about the requirements (function and non-functional) and testing if the code fullfills these requirements. This means that Unit-Tests are not enough and functional integration and acceptance tests will be needed – normally these test will be defined and implemented together with the domain experts and experienced testers in the team. But especially for automated testing a developer should be involved from the beginning to code and design for automation – e.g. to provide data-setup and deal with time and dates in the tests. For me, automated regression tests are a must-have if you are developing in short iterations – otherwise the test effort can explode. Especially when Test-Driven Development is introduced, the developers will need training and coaching to get their tasks done. Today test-driven unit tests can be found in some projects but test-driven integration- and acceptance tests are really rare.

The developer will have to communicate a lot with the domain experts to transfer the elements of the user stories into good tests. Good knowledge of the domain will be also more important as the detail level of user stories are much lower than of classical use cases. This means that developers will need very good communication skills and a toolset of practises like Domain Driven Design. Today developers concern more about frameworks like Spring and Hibernate than with the business domain; generators that transfer an Entity-Relationship-Model into a Domain-/Object model are a nice gimmick but more or less useless! The generator will not help to get a good structured domain that can be used as a communication bridge between development and the domain experts. DDD calls a good domain model UBIQUITOUS LANGUAGE – One team, one language! In agile teams, where domain experts, testers and developers are working in one team on the same tasks and stories, it is essential to have one language. So in my opinion we need to sharpen the domain and design skills of the developers, so that they can communicate with the domain experts in a clear and simple manner.

To deliver software every 2-4 weeks a developer should also have good knowledge of common agile practises and tools. Continuous Integration (e.g. Hudson, CruiseControl), automated build tools (e.g.. Maven, Ant), code quality analyzers (e.g. Findbugs, PMD, Checkstyle), test automation frameworks (e.g. JUnit, Robotframework, easyMock, DBUnit, JMeter), version control systems (e.g. git, Subversion), bug tracking (e.g. Jira, Trac), documentation tools (Wiki, UML, Javadoc) are just examples of the modern, agile software developers portfolio. These practises and tools have to be trained, adopted and optimized so that they can be used for higher productivity and high quality results. Dave Thomas, Co-Autor of „The Pragmatic Programmer“, defined so called „Code Katas“ to practise what is needed to be a professional developer.

In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions.

So despite the training, we also have to give our developers time to practise – for example to learn TDD as seen in this Kata by Arne Roock.

In addition to all these skills, the developers have to be trained to understand the overall process and concepts. Today the focus of Scrum trainings is on Scrum Master and Product Owner (Ken Schwaber is changing this with the Scrum Developer) – as most of the meetings and artifacts are mainly for the “team”, we should sharpen their understanding of Scrum (which is also part of the ScrumMasters job). For example the team should learn that the main idea behind Daily Scrum is not to report to the Scrum Master (who does not even need to attend the Daily Scrum) but to synchronize with the other team members and make impediments transparent. I’ve seen a lot of Daily Scrums where the ScrumMaster moderates and asks each team member the three questions and updates the Scrum board for them! Also the Burndown Chart is an instrument for the team to track the progress of the team – it is not used as a control-instrument for the Scrum Master or Product Owener (or even managers). Anyway: Team members have to be trained and coached to understand Scrum and the agile concepts.

This all shows that organizations that are moving to agile methods like Scrum will have to change. The skill-set of the team and especially developers is changing and the spectrum of required skills will demand for more training, practise and knowledge transfer. „The New New Product Development Game“ claimed that: „Multilearning“ and „Organizational Transfer of Learning“ are two of six critical success factors for good product development teams. Agile organizations will have to accept that training is not an incentive but a duty for all team members of agile projects. The invest in the employees will pay off for sure!

These days I concentrate myself on learning about agility and I recognized a lot of similarities between agility and the Vikings Law.

Has it been their secret of being able to reach America a long time before Columbus? Let` s have a look…

Each Viking law has several bullet points, and there are some of them:

• “Be versatile and agile”
  Even if you are an Developer and as the most of them not really athletic, at least intellectual, you have to be versatile and agile
• “Don’t plan everything in detail”
  Isn’t that what we can find in User Stories and incremental development?
• “Attack one target at a time”
  One task after another, maybe they have had Burndown- Charts in the past (Probably they had more Burndown-Villages)?
• “Be Direct”
  Also Vikings knew to appreciate the direct contact to their customers, even without their cooperation…

These are not all bullet points of the first law, but I think that it will be enough for my first blog post.

Maybe, these hidden agility was one of the reason for the success of the vikings? In future posts we will find more evidences for this theory.

P.S. Preikestolen (N58 59.183 E6 11.322), really beautiful place and a good chance to pop the question

Before, within an open space session Boris had presented his point of view on the role Product Owner. Throughout this presentation I realised that this role has a lot more elements of the conventional project manager role than I thought before. I got the perception that the responsibilities of the conventional project manager became distributed across the roles Product Owner and Scrum Master in a certain way. Having this picture in mind I asked Boris about it and he confirmed my perception. To be exact, he even extended it a bit:

From his point of view the conventional project manager role is overloaded and there is hardly a person who is capable to fulfil all responsibilities of this role in a reasonable way. On the other hand in Scrum the role is split up the following way:

• The Product Owner is responsible for direction (the vision), control with regard to content (Product Backlog) and the budget. He is the one who sets the direction and drives development with regards to content. He also tries to make the most of the available budget. No matter how the project looks in detail – since the features that promise the highest business value are relatively also the best funded features, the pursuit of making the most of the budget automatically leads to a priorisation of the features by their business value. Now, this might not sound “noble and pristine”, but in practise this works surprisingly well …
• The team is responsible for planning the implementation and sticking to its plan, i.e. the whole detail planning and controlling tasks. Using concepts as sprint planning, commitment on the negotiated sprint contents and team responsibility for the implementation, it is much better guaranteed that expectations and results fit together than in conventional projects.
• Finally the Scrum Master is the “care taker”: He takes care of the pizza if it becomes late and he smoothes the impediments out … but he is also the guy who looks over the teams shoulder and reminds it of its commitments if necessary. He makes sure that everybody fulfils his individual role and he cares for the best working conditions possible.

This way the responsibilities of a conventional project mangager are split across the three Scrum roles in a quite straightforward fashion. Thus, if a project manager wants (or sometimes is urged) to move into Scrum it is quite easy for him to select the appropriate role. He should figure out for himself honestly which part of the project manager role he likes the best:

• If he likes most to drive a project with regard to contents and has a way with budgets, he should take the Product Owner role.
• If he is more of a “care taker” and loves to make sure that a project is running smoothly, he should take the Scrum Master role.
• If he became project manager in the first place because he was simply too good in his former developer role and somehow slipped or grew into the responsibility this way, he should become part of the team best and enjoy to push the project along with his own effort.

Alltogether Boris point of view makes a lot of sense to me. Especially I think that this way the critical responsibilites for project success of the conventional project manager role are split up well across the three Scrum roles. Also I think that these responsibilities are handled much better by three persons than by one person.

Anyway, one point Boris left out in his presentation: There is a kind of conventional project managers that can be met quite often. I like to call them “pure project managers”. They manage projects in a pure formal fashion without having a deeper insight of the project contents. They limit themselves to manage plans (whoever created them) as well as escalations. They posess distinct controlling knowledge, sometimes also good political skills. Following the “management by spreadsheet” metaphor (management on the basis of key figures only neglecting the underlying business contents) they do a “project management by spreadsheet” and some of them are even proud of the fact that they don’t know anything about the contents they manage (“I can manage any project no matter what it is about.”).

Now, for this kind of project managers Scrum actually has no usage. Following the lean principle “Eliminate waste!” Scrum avoids any kind of dead freight and focuses solely on those aspects of the project manager role that provide added value, i.e. add directly to project success. And since real success can be judged finally on the basis of the produced results only, a person that cannot contribute to the project contents, to the actual result is not needed in Scrum. The only question left is, if such a person is needed outside of Scrum …

What’s special about agile teams?
They have the authority to act, are self-organising, share ownership and (interesting!) any two can make a change to product, process and tests. This somewhat confirms what Boris Gloger said, that everybody in the team should be able to do 90% of the work, but adds that if you take any two team members you should have 100% of the skills covered. (I have to ask our mathematician Dr. Snatzke to figure out how to distribute the skills amongst team members to fulfill these two statements at the same time). Actually, Reid said that you need two to agree on making a change happen, I just assume that these two then can also carry out the change.

Is it also that agile teams are highly-motivated, highly-skilled and cross-functional? Generally, the kind of people in traditional and agile teams are the same. With an skill matrix you can identify which skills are underrepresented in the team, in this case DB and bond trading skills are lacking in the team.

What kind of skills do you have in that matrix? You can distinguish long / deep term (DB, Test) and short /shallow term skills (Java, Swing, FitNesse, Bond trading). For example, once you understand the underlying principles of programming, moving from one programming language to another is no such a big problem. So in agile teams you really need the long term skills and deep understanding.

Short term skills are project specific and can be relativly quickly trained.

Skills can be broken down into several categories:

• Development: Design, Programming, Build, Integration, Testing, Technical (Middleware, Database)
• Management: Planning, Enforce ‘process’, Conflict Management
• Customer / User: Requirements (Stories), Acceptance Test, Business domain knowledge, user manual
• all of them overlap in some places
• Plus: collaborate and communicate

Where do these skill sit in the organizational structure? So we have the management level and agile team level, but there’s also the need for a place to put specialist skills (like security). As well, we apparently need also non-team specialist testing skills. This very much reminds me of codecentric’s current organization with agile teams and competence centers (one being Agility and Agile Testing one of the core topics!)

The testing skills that you need within the team are basically the same that you also need in traditional projects: test design, exploratory testing, test tools, TDD, etc.

How are the skills distributed to the roles. While it might still work if you only have developers in the team, because they can take on also other roles, things can get complicated if you for example only have testers and business analysts (personal comment: are there really such teams?!)

• Management: Scrum Master, Lead Engineer
• Development: Designer, Programmer, Tester
• Customer: Business Analyst, Tester

Testers can not always program (Reid said that), so depending on the testers background the team of testers might acutally work or not. What if you don’t have a Scrum Master, because you have a project manager, who cannot let go, and don’t trusts the team? According to Reid, the cross-functional team member is a myth, but a great vision to aim for.

So what capabilities (not skills!) does a Scrum team need? on start-up it’s suggested that 2 or 3 of the team are both competent and experienced in agile, because they need to spread the skills. You need a good mix between experience (in terms of time spent in the industry) and skill level. Agile teams self-optimize to get tasks assigned to the team members, who can best do the job. Agile teams do hide “nice but dim” characters from management, but do not tolerate clever but selfish non-team players. In the end, no-one can hide from the other pigs in an agile team, much unlike in traditional development.

How are Scrum teams organized? Certainly not hierarchically. but for example in pairs. You normally have the roles of Driver and Navigator, while the Driver is the one who is learning (and typing), and the Navigator has the expertise and can transfer the knowledge. Another model to use is mentor/apprentice (think Dumbledore/Harry). Example pairs are BA/Tester, Developer/Tester, BA/Developer, Tester/Developer. Reid recommands to rotate the pairs only if really needed, if somebody needs some specific skills of somebody else, otherwise you might end up working with somebody you don’t like. Not sure I really agree with that, the whole team should be set up so, that everybody get’s along with everybody else pretty well, so it’s also a question of how you decide who belongs to a team, that’s not only a skill-based decision!

What if you need a skill in a team, and don’t have it in your team. Here are some ideas: new staff, contractor training, coaching. Team should be empowered to organize this for themselves. Beware of contractors going native, get rid of them, as soon as the skill is transferred. If you don’t you are paying them more than your own employees but they can only do the same work, have no more skills to transfer.

Quick show of hands who is certified by ISTQB – quite a lot are even advanced certified!

How to motivate team members? Certainly not by pay (so true!). You can motivate by design the job properly, for example with these factors as identified by the Motivational Potential Score. Any score below 60 should not be carried out by a human. So which are the most motivating test related jobs? The take-away is that the score is generally higher, if you are on an agile project, except for the Business Analyst, because they think they are very important people in traditional projects, and now they are just part of the team. The increase from traditional to agile is about 25%. (I will blog more about motivation and Scrum in the future, so stay tuned).

Reid finishes with the conclusion, that it feels good to be on an agile projects. And I can ful-heartedly agree on that one!

Correctness can be confirmed at any time is the subtitle of Mary’s talk and it start off with the clear statement that Waterfall does simply not work. So let’s hear what works .

The question is how to deal with complexity and the answer to some extend is divide and conquer. Mary continues with some history on how to archieve this. Basically everything has been “structured” back in the 70s, which does also not really solve the problem as we know today. But what we really want is not to inject defects already from the very beginning. An early answer to this was given by Edsger Disjkstra which basically was a form of layered architecture.

After the long discussion about architecture with Tom Gilb yesterday night in the hotel lobby my fingers are not too calm while writing about architecture here … but back to Mary. The question is how has the software to work on various levels? E.g. unit level testing and business level testing.

Next in the history is Harlan Mills with his Top-Down Programming approach, which should help avoiding any difficult integration. It’s a kind of step-wise integration, which could be seen as an early version of continuous integration what we discussing today in agile. So as with the discussion wth Tom yesterday it seems that quite some agile ideas are not really that new.

Next in history is Dave Parnas and his “Criteria of Decomposition”. This immedietly reminds me that Tom was saying that too many archtecture are doing nothing but decomposition and this is not architecture, but this is again another story. The idea was to divide the program to ease future changes … so this comes close to the idea Uwe is promoting, which is “Architecture for Maintenance”. And sorry I have to admit here I was too slow to keep up with the hstorical view, but we will catch up. (At this point Andreas and me are pairing on this blog entry, very cool.)

1976 it is analysed that the main problem in software development is maintenance costs (again) and the solution to this problem is to find defects early! For this shorter development cycles are needed than in the known Waterfall process.

1981 Tom Gilb is hitting the scene with the concept of starting with a short summary of the measurable business goals of the system. Those must be unambigious, testable and must not contain design. Hmm, sounds very familiar as it is basically the core statement of his lecture yesterday. It is always very nice to get these kind of “cross connections”. So we are back at:

“Prevent defects injection in the first place!”

How to learn how to avoid defect injection? Right, let’s think of a “Defect Injection Process”. It starts with a Specification and one team writing the code and another team writing the Tests. Sorry, this does not match at the end and we have a defect injection process. Next idea: Combine writing the tests together with the specification and then write the code to implement the expactations imposed by the tests.

Back to “Conquering Complexity” and the question how to deal with complexity and the answer is divide by reposibilities and value. This evolves to the three rules of lean development:

• Design matters
• Correctness can be confirmed at any time
• Failure is a learning opportunity

Mary continues with some quite high-level examples how to develop a system. Of course she is making “bonus points” by referring to the “iPhone” as a good example for such a good design of an overall system.

Now it gets more concrete again with the question how much time of the release cycle is used for finding and removing bugs (system hardening)? The answer is that top companies are only using less than 10% for this while sometimes even 50% of the time in a release cylcle is used for this. But it cannot be the aim to use that much of your valuable development time for this, so find defects earlier in the process. And with this Mary comes back to the topic that you can confirm correctness of your software at any time and not only at the end of your release cycle.

“No correlation between size of the code base and bug rate: Complexity handled completely.” (from an example developing an embedded system)

Now we come to Agile: We have short and stable iterations. And the stakeholder can give and gets feedback every iteration. And this would not be called “Agile Testing Days” without a good example how automated tests have let to a very successfully project when IBM was introducing agile. Sounds like continuous integration and early automated testing, even without FitNesse and Robot.

“People do not want software, they want something else.”

Basically people want their top objectives implemented and thus problems solved. Mary is also promoting TDD to archieve this.

“The biggest defect is tolerating defects.”

And Mary is emphasizing that you must learn from failures as it indicates a lack of understanding. This is always an opportunity to learn. Anyway, in a very diciplined program only a few defects will escape.

Ok, as we are talking about lean here there must be some example from Toyota . Mary describes how Toyota is coming from the current condition to their vision. For this you need to overcome one obstacle with every step to come closer to your vision.

Andreas sums this up that a lot of this was already discussed on the tutorial on Monday, but it was good to have it repeated again.

Visited and written by: Andreas & Thomas

The answer to the question from the tile of this keynote is: Yes! As already partly in the tutorials yesterday Lisa has again emphasized how important it is that there are no silos in agile teams. Instead it is all about solving the given task (developing quality software) in a collaborative mode. To do so (agile) testers are as important as (agile) developers and all other potential members of the team.

Lisa Crispin: “We (testers) don’t break code, it comes to us already broken!” (im Original von Cem Kaner)

All in all Lisa’s keynote was very inspiring as she put a strong focus on agile values and ideas and how they help having more success in software projects and in the end also more fun.

Luckily other visitors of the conference are also blogging and thus we can keep it a bit shorter here – as this will anyway be a huge blogpost – and link to some posts on Lisa’s keynote.

• Gojko Adzic: Are agile testers different?
• Anthony Gardiner: Lisa Crispin – Are agile testers different?

Open Source Agile Testing by Péter Vajda

Visited and written by: Andreas

This session should have been called “How to not implement Scrum”. Péter Vajda presented his experiences as agile coach in the Nokia Maemo project, the linux based operating system for mobile devices of the future, like the well known and valued internet tablet N900.

Two years ago, 200 employees were part of the project, by now they grew to nearly 1000 people and 50 teams (which implies a teamsize of 20). While the gap between open source communites and a mobile device manufacturer has to be bridged somehow, it was decided to go agile and introduce Scrum, use XP practices and Lean thinking.

Beside some well known facts (scrum teams should be co-located), some interesting facts were shared. For example they realized in Sprint 20 that unit tests alone do not suffice, automated acceptance tests were nice but not existing. What to do? Take a break and create acceptance tests for all functionality from the last 20 Sprints or leave that functionality uncovered? The compromise was good from the content, having a “refactoring backlog item”, but also if you have “system user stories” you should always make clear what the value is. And the value of that is not the test itself, but that you gain confidence and flexibility to integrate new features more easily.

The demo, which showed how to test a Qt calculator with cucumber (the real new toy / gadget could not be disclosed, unfortunately) at last brought some new insight: With cucumber you can write behaviour tests, which not only support the format “given / when / then”, but also support a postfixed table with additional test data. An idea I was exposed to already at Agile 2009 in Chicago, but there in the context of FitNesse: One problem with given-when-then… the answer… “Other Examples Include”. I think that this is really a great idea to describe behaviour in the appropriate context and provide additional test data / examples.

Agile Testing: A Report from the Frontline by Joke Hettema und Ralph van Roosmalen

Visited and written by: Thomas

Joke is starting her presentation with a short introduction why the company she is working for has switched to agile methods for their projects. Here a common pattern was repeated that traditional methods could no longer give the required visibility as the projects became more complex. To solve this Scrum has been introduced as an agile method and mixed teams have been setup with developers, testers and architects in one Scrum team. Up to here not too much new I would say.

With respect to Testers and Testing some patterns from the tutorials and Lisa’s keynote are repeated: No explicit testteams anymore, shared responsibilities for developing and testing the software. But one special thing here is setting up a “Scrum of Scrums” for all testers of all the different teams only. Of course information sharing is important, but for me this goes into the wrong direction as it again draws a borderline between testers and developers instead of bringing them together. This borderline is getting even bigger by establishing special Sprint planning meetings for testers only where testing tasks are planned independently from the (other) development tasks. After a question from one visitor it also turns out that developers are only writing unit tests, but for all further testing they rely on the testers to implement those. Again this sounds as if there is still quite some borderline between testers and developers inside the teams.

Then Joke describes the problem of “Mini Waterfalls”. Those are happening still too often for them due to the fact that developers are not checking in their work frequently enough, pilling up bigger chunks of work that are then committed in one go. On this topic I can only recommend Fabian’s very good post on committing frequently that he has written some weeks ago.

When it comes to sprint planning their is again a level of indirection I personally do not like. This comes due to the fact that only some “Functional Specialist” is talking with the product owner and is then talking to the team instead of having the team talk directly with the product owner. A similar question came up yesterday in Elisabeth’s tutorial and here statement was clearly that as many team members should be “allowed” to join the sprint planning meeting as possbile. In addition I personally doubt that it is a good idea to have domain knowledge bundled only in a specifc role. But we are slowly leaving the area of agile testing, so back to topic.

Joke continues by showing the documents that are produced and the tools that are used for testing, which – again – does not make me feel too agile: Test Strategy, Risk Matrix, Test Approach Document, Checklist, Session Tester and Bug Reporting Software. With respect to the “Definition of Done” she points out that it is very often the “task” of the testers to tell the rest of the team that the definition of done is violated while the rest of the team is arguing against this. It also seems that the trust in the definition of done is limited as their are additional sprint only related to release testing where then a lot of manual tests are executed. Sounds a bit like classical release testing which would also fit that there is a dedicated role of a test manager.

All in all I think the presentation is a good example that – at least in this case – there is still some way to go at the “frontline” to get rid of the existing QA methods and going even more into the direction of agile testing.

BDD approaches for Web Development by Thomas Lundström

Visited and written by: Andreas

At first Thomas Lundström layed some basics for BDD and set the context for the following live demo. This first part of the presentation took a little bit too long for my taste, you could expect that on a conference for agile testing, everybody has a rough understanding what behaviour driven development is. And then, some parts were explained differently to what I consider them to be correct, for example the “golden triangle”, the fusion of requirements, tests and … done?! To the best of my knowledge, and this is also how Gojko Adzic explains it in his book “Bridgin the Communications Gap”, executable specifications union requirement, test and examples (to explain the requirements). The presented combination of cucumber and webrat, ruby based tools, were capable of testing a simple guest book webapp. Ok, user stories are called features in cucumber (or rather in Gherkin, the DSL), and acceptance tests are not called acceptance tests, but scenarios, but these are just minor issues. Webrat does not support Ajax, so it is really only usable for simpler use cases, but cucumber also supports Selenium and HtmlUnit.

A very important point was underlined by Lundström, and I don’t want to miss amplifying it also here. It is important that automated acceptance tests / executable specifications describe the rules that should be tested – including the context and prerequisites, but without the concrete steps / the script how to get there. Creating the context is what the fixture should do. Lundström gave the following example and differentiated between the imperativ style (the script) and the declarative style. By restricting the test on the logic that should be tested, the declarative stype is much more robust. An additional advantage is in my opinion that it opens the possibilities to automatically refactor the fixture (the binding between the test and the code under test), if it is written in the same programming language as the system under test. An impossible thing, when the context creating logic is part of the test script.

Imperative Style

Story: Animal Submission
 
  As a Zoologist
  I want to add a new animal to the site
  So that I can share my animal knowledge with the community
 
  Scenario: successful submission
  Given I'm on the animal creation page
 
  When I fill in Name with 'Alligator'
  And select Phylum as 'Chordata'
  And fill in Animal Class with 'Sauropsida'
  And fill in Order with 'Crocodilia'
  And fill in Family with 'Alligatoridae'
  And fill in Genus with 'Alligator'
  And check Lay Eggs
  And click the Create button
 
  Then I should see the notice 'Thank you for your animal submission!'
  And the page should include the animal's name, phylum, animal class, order, family, and genus

Deklarative Style

Story: Animal Submission
 
  As a Zoologist
  I want to add a new animal to the site
  So that I can share my animal knowledge with the community
 
  Scenario: successful submission
  Given I'm on the animal creation page
 
  When I add a new animal
 
  Then I should see the page for my newly created animal
  And the notice 'Thank you for your animal submission!'

Quelle: Imperative vs Declarative Scenarios in User Stories

Introduction to Robot Framework von Pekka Klärck

Visited and written by: Thomas

Even though Andreas was telling me before the session a thousand times that I anyway know everything about Robot Framework and there is no need for me to visit this track, I could not resist to see Pekka in action and getting some first hand information on the latest features in Robot. Pekka did not disappointed me.

First of all a few basic facts: Keyword-driven, based on Python, supports Java using Jython. Support for other languages via XML-RPC remote interface. Robot is Open Source under the Apache 2.0 licence. The tool evolved out of a thesis work that was started at Nokia Neworks and is today still supported by Nokia Siemens Networks. But I think this is enough of repeating the basic stuff as the slides are anyway available here .

The presentation continues with the explanation of keywords. Of course here Andreas is right that there is not too much new for me, as I am dreaming already in keywords. It goes on with a very short comparison with FitNesse and Pekka points out that in Robot everything is a keyword, which makes things very easy to understand in comparison to FitNesse where there are different kind of fixtures one has to understand. The example that is shown afterwards looks quite familiar as Elisabeth was using it as well for her tutorial yesterday. Now Pekka is emphasizing a great strenght of the Robot Framework, which is combining lower-level keywords to more powerful higher-level keywords. A feature in which I also personally see as a very big strength of the tool. By the way, it is quite facinating following the presentation on some Unix machine where all the menus and related items are completely in finnish language.

Pekka Klärck: “I have some confidence that really every tester – even without the slightest programming skills – can combine existing keywords to build new testcases.”

Pekka continues by starting Robot from a shell. It is pointed out that this is especially important for integrating Robot with CI-environments, which is really an easy task to do with Robot. Then the reporting and statistik capabilities of the tool are shown, especially the tagging. This is building a bridge to the tutorial yesterday where there was the question how to prevent that the build fails due to already implemented tests for which no functionality exists yet. So tagging is one half of the answer together with the possibility to define that tests marked with certain tags are not critical. Thus when those tests are failing the build is not marked as broken, which is not only a wanted effect in ATDD, but more a mandatory thing any agile testing tool has to support.

The graphical editor RIDE has also made great progress. It is now possible to extend keywords using CTRL-Space. RIDE shows then all keywords starting with the given characters together with the documentation of those keywords. This is really looking very promising and I personally think that the “final” version of RIDE will be another big boost in the usability of the Robot Framework. The same is true for the new possibility of “Executable Specifications” which will be worth a blog post of its own still.

After the presentation and during lunch there was some time for a quick chat with Pekka, which I was very happy about as we worked at the same company at the time Robot was developed and Pekka was visiting us a lot to promote the tool. It also showed me again that the development of Robot is very actively happening and I am looking forward to the things happening with RIDE and and the ATDD feature (and everything else).

Key Note Elisabeth Hendrickson – Agile Testing, Uncertainty, Risks and Why It All Works

Visited and written by: Andreas & Thomas

First of all Elisabeth really has a very good and active presentation style. Her presentation was mainly about what she calls the “7 Key Principles of Agile Testing”. Those are:

• ATDD
• TDD
• Exploratory Testing
• Automated System Tests
• Automated Unit Tests
• Collective Test Ownership
• Continuous Integration

Anthony Gardiner has already written more on those in his Blog Post ob this keynote.

Elisabeth Hendrickson: “The only way to tell if you are agile is if you are successfully delivering software.”
Elisabeth Hendrickson: “Exploratory Testing is a dicipline. It is not just blindly banging on the keyboard.”

I am not sure whether or not it is some kind of sign that I was initially writing “keyword” instead of “keyboard” in the quote above . But back to the keynote: It sontinues with CI and an explanation that tests are artefacts that belong to the project. I fully support this and I find it hard to understand that there are still projects that do not have there tests and test documents under version control same way the code is under version control.

Agile Quality Management – Axiom or Oxymoron? by David Evans

Visited and written by: Andreas

David Evans presented some traditional testers’ concerns that are moving into an agile environment and put them into a different light. For that he used an interesting structure, every concern was formulated from the pessimistic perspective (as oxymoron) and from the optimistic perspective (as axiom). Which of the two is the right one, I leave that as a homework to the reader

1. Developers Test Their Own Code
   • Oxymoron: Marking your own homework
   • Axiom: Unit tests are the first of many qualtiy strategies
2. Developers and Testers are co-dependant
   • Oxymoron: Independence is fundamental to quality governance
   • Axiom: whole team share the goal of creating quality software
3. Developers know the acceptance tests (are defined and agreed up-front)
   • Oxymoron: they will only write code to make the tests pass
   • Axiom: they won’t write code that makes the tests fail
4. No Signed-Off Requirements (.. seem to change with the weather)
   • Oxymoron: I can’t possibly certify that the requirements have been met
   • Axiom: Each requirement is defined by its acceptance tests: these are negotiated with and confirmed by the customer
5. No Test Plan (IEEE 829 Test Plans are in short supply on agile projects)
   • Oxymoron: Failing to plan is planning to fail! How will we know what to test?
   • Axiom: The Test Plan is impled in the product backlog: everything we build, we test (don’t build tests you don’t care if they fail!)
6. No Test Manager (or Test Management Tool) (Test Manager is not a role that exists in Agile literature)
   • Oxymoron: so how can we possibly manage testing?
   • Axiom: Testers == team; tests == specifications; … they don’t need separate management

After that he offered some recommendations for quality principles, but there have not been bigger surprises hidden (fast feedback, shared “done” understanding, etc). The right testing attitude was exposed for example in these quotes:

“Defects are evidence of missing tests”

“Any test worth writing is worth running all the time”

Means, when a test is “red” and the customer does not care … delete the Test. It was not worth writing in the first place, since apparently it was testing not needed or wanted behaviour.

Quality and Short Release Cycle von Lior Friedman

Visited and written by: Thomas

Lior starts his presentation with the statement: It is not the task of a developer to just create code, but functional and quality software. I can only say “yes”, but why is it so that this must be emphasized so often? It seems crystal clear to me that developers want to create value for the customer and it not programming for the sake of programming (this can be done in some spare time ). For me this is all about a professional approach to software development.

It continues with a discussion about Time versus Quality and the fact that in traditional projects there must be always compromises if the amount of Resourcen is fixed. With agile methods time should be saved by producing better quality at the same time.

I think for the rest I can keep it short as there was not really too much new. The presentation discusses the advantages of short release cylcles, better quality due to CI, less bugs, better efficiency, more trust from the customer side and less risk. To sum it up: The reasons why we are doing agile software development anyway.

“Testify” – One-button Test-Driven Development tooling & setup by Mike Scott

Visited and written by: Andreas

In the beginning there was some overlap with the earlier presentation from the SQS collegue David Evans. But quickly the live demonstration of “Testify” started, a tool to create a fully configured, with all bells and whistles, TDD/ATDD (Acceptance TDD) project setup; either in .Net or Java. This SQS-internal tool is open source from today on. Thanks Scott!

• .Net integrated tools: nant, nunit, fit, fitnesse, richnesse, selenium, ncover, nsis, fx-cop, cruisecontrol
• Java: here the toolsbelt looked similar, but I was too slow to note it down

Essentially, Testify is a carefully crafted project, in which some files are turned into velocity templates to replace the project name (the only parameter the testify wizard accepts) in some files and filenames. Personally I would have chosen Maven Archetypes to do that, because technically it is doing exactly that (and a little bit more), but ok, you don’t have a UI for that. If you don’t have any tool preference or other constraints, you should invest 2 hours into the generated project and see if it fit your needs.

Test Driven TDD – TDD quality improvement based on test design technique and other testing theory von Wonil Kwon

Visited and written by: Thomas

Sorry, but here a summary does not really make muh sense as the whole presentation was really low-level and there was nothing really new. Furthermore the examples did not really make much sense. Sorry Wonil.

Key Note Tom Gilb – Agile Inspections

Visited by: Andreas & Thomas, Written by: Thomas

Yiihaaa, it is 6pm and Tom start his keynote. So far I never had the opportunity to see Tom live and half an hour later it seems as if this is not really what some visitors have been expecting as it seems that agile is no topic at all in his presentation. More to the opposite as at the end of this talk he is firing with big canons at agile saying that “yeah it’s nice you guys do your standup meetings and have fun and everything but no one needs those in real projects. There you need measurable results!”

Tom Gilb: “It is you’re fault if you accept garbage in!” (about testers accepting bad requirement documents)

And that is the key message of Tom’s talk: How can I find the amount of potential defects in requirement specifications and minimize them? Because for two defects in the requirement specification there will be one bug later on in the software. At this point in time Andreas was sitting next to me and was already a little bit agonised as he was missing the agile background and at the same time he was a bit flashed by the slides. But I have to say: I really liked it and therefore I wanted to write a bit more on it still .

Tom Gilb: “Garbage in guarantees some garbage out no matter how clever you are.”

Ok, so requirements are the topic. No “Executable Specificqations”, no fancy automated tests but a way to find potential defects in requirement documents. I think it is quite obvious that Tom wants to be – and succeeded to be – very provocative with his statements, especially at a conference focusing on “Agile Testing”. But I am a big fan of looking at things from different angles and I think Toms’ approach can very well be seen as something that can be used in addition and it does not really contradict with the agile testing practices - used anyway at a later stage in the project - discussed so far.

Tom Gilb: “How lucky do you feel today, punk?” (About the 50:50 chance that a bug in the requirements results in a bug in the final software.)

The discussed method is analysing specification documents with respect to the following three rules:

• Clear enough to test is.
• Unambigious with respect to intendend readers.
• Contains no design.

With this approach you can now analyse some pages of a given requirement specification and get “the amount of defects per page” as a measurable size. For this it is enough to have a group of stakeholders analyse the document for about 10 minutes. I skip some of the details here, but in the end you get some number indicating the amount of defects which gets multiplied with some Tom-Experience one page of requirement specifications containing roughly 300 words in average. (Tom had some even more extreme examples with up to 600 defect in a page containing only 300 words.) This seems to be a normal value when looking at specifications that have not been written with any special focus on the rules shown beforehand. With 60-100 defects on one page this would mean already 600-1000 defects on a specification with only 10 pages. With 50% of them ending up as real bugs in your system that must be found and fixed this shows how dangerous this is for projects … and how expensive.

I really think this is a very good approach to check requirement documents (also together with a customer) and is worth trying out on ourselves. Of course Tom also has some solution for this problem by describing requirements in a more formalized way. For more information just use google to find Tom’s book. Of course there will be also some other ways of solving this once the problem is identified. In the end this means that with this we will get excellent input for our “executable specifications” and then I think it is also ok for Tom that we have some fun using our agile methods and everything … as deep within him he can for sure as well see some value in this .

Chill out/Dinner Buffet – Oktoberfest

Visited and written by: Andreas & Thomas

The evening event was done using the Oktoberfest as a theme. Well, we are both not the biggest fans of this and the loud music was making it very hard to continue any meaningful discussions. But anyway it was fun and was of course a nice idea.

Later the evening we are moving to the hotel bar to find still some people for some discussions and to finish this “monster baby” of a blog entry. This is of courese worth a quick agile retrospective and we decide to use a different approach tomorrow by publishing smaller blog posts more frequently. This will minimize the risk to produce something that in the end no one needs as it might not get ready in time for the end of the conference .