Work In Progress
When I started at this team, they had one major issue: getting things done. The major symptom was the frustration of management and the team with the project. The first 3-week time box (sprint) ending with about 30% (!) of all features still in progress, when, of course, they should all have been done and ready for shipment.

Their existing solution to this problem was to lower the expected velocity each sprint, so the next sprint would be on-time. But at the end of next sprint, the same problem occurred, so the velocity was going down sprint after sprint. The sprint planning meetings weren’t very pleasant, as the failed commitment hang heavily on the team and there was still the pressure of the rest of the organisation for the team to keep up their tempo. This pressure from both sides was crushing morale.

The way this team reacted to pressure was to work harder. Most people would have 2 or 3 tasks in progress at the same time. When a developer would finish a task, the testers were too busy testing something else, so they could give the developer direct feedback. When the tester found an issue with a new feature, the developers were already working on something else, so the tester had to wait. Simply put, there was too much focus on working long and hard, not on cooperation and the stuff that actually matters: features.

I’m believe most dysfunctional behaviour comes from the system people are in, so I first addressed the biggest struggle of this team: pressure & predictability. Most Scrum masters challenge the team to reach the same (or higher) velocity each sprint. This pressure should give a team focus to perform at its best. However, it can also go haywire if the team doesn’t deliver. No focus, no pride, no happy customer. The effect on this team was that retrospectives were dismal and planning meetings were a huge burden. The teams’ productivity dropped in the days after the sprint, finding new courage to start the next one. Because they had an ineffective work-process, the only outcome of each sprint was to lower the expected velocity, to make sure we would be predictable. Estimation and predictability are only a means to an end and since they were getting in the way of fixing the root cause (and were bringing down the team’s spirit) I opted to cut out the planning sessions and sprint deadlines.

Kanban
The solution was inspired by Corey Ladas’ presentation at Agile2008 about Kanban. One of the tools Corey adds to his project is a limit of ‘work in process’. This was exactly what the team was struggling with (remember the big pile of unfinished tasks?). So the first change we made was to set a limit of 8 tasks on the ‘in progress’ column.

We spent 3 weeks bringing the numbers of open tasks from 21 to 8, without picking up any new work. Of course the team struggled with this new limit. They were used to pick up new work whenever they were blocked somehow, this wasn’t allowed any more. It took some time for the team to really learn that picking up too much work would mean regression to the swamped way of working. Resisting the impulse of increasing WIP is still a discipline, but we now keep each other in check. This gave a stronger team focus on getting stuff to done and recognizing the systemic issues (impediments) with the flow of features.

We used the term Feature Flow to describe the goal of the team: to let features flow through the team without interruptions. Any feature that is in a state of waiting, or is simply taking more than a few days is analysed. It’s moved to done as quickly as possible by scrambling more team members. When we encounter features getting stuck, we don’t pick up more work, we try to find the root-cause of the stickiness and solve that. We increased the quality and capabilities of our build environment a few times for that very reason: to prevent future blockage in our flow of features.

When we introduced the ‘work-in-progress’ limit, we also temporarily stopped doing planning meetings, as our first target was getting the w.i.p. down to 8. The interesting side effect was, that we were working for a few weeks without the need for a planning session. So we stopped the fixed-date planning session and replaced it with an ad-hoc planning session whenever the ‘sprint-backlog’ was drying up. From our coarsely estimated product backlog our product owner introduced a couple of days worth of features each planning session. The great thing was that the priorities could change at the last moment, as long as the team hadn’t started working on a feature. As the Sprint planning meetings were always quite strenuous, the just-in-time one-hour planning sessions kept the teams energy at a constant.

This simple Kanban process worked pretty well and our velocity increased back to a decent level. In my next blog I’ll explain some extra improvements we’ve made, how we got the testers and developers to stay in sync and why we’ve introduced some lightweight planning again.

Lean is a process management philosophy derived from the Toyota Production System that aims to provide more value with less work. Lean originated from mass manufacturing, but has successfully been applied in other industries such as health care, travel industry, and services. That means Lean can also be applied in software development.

Although Lean is becoming more popular in the Agile community, the views on what Lean is, differ widely. Martin Fowler tries to avoid the entire Lean vs. Agile debate by stating that they are equal. Although the idea of keeping Lean within the boundaries of Agile has its appeal, not everyone agrees.

Some see Lean as an improvement on Agile. Alan Shalloway from Netobjectives sees Lean as ‘Agile in the Enterprise‘, referring to the ‘value stream’ thinking tool that Lean offers. In a Value Stream Map, the entire process of delivering value to the customer is studied and improvements are made based on the biggest problems in the stream instead of optimizing only small parts. In an enterprise environment this could provide a lot more reduction of waste than a regular Agile approach. Scott Ambler refers to the local optimization of Agile as silos, although he might not think of Lean as removing these silos.

Lean is also used to criticize current Agile methods such as Scrum. Tobias Mayer loosely quotes Marry Poppendieck in his blog claiming Scrum being “insufficient”. This triggered a response by David Anderson; one of the most profound contributors to the current rise of Lean in software development. David presented Lean concepts at Agile2008 in his talk ‘Future Direction for Agile‘, opening up Lean as a way to improve further on Agile.

For many, Lean will be used as a set of (thinking) tools that can aid in tuning current Agile practices. A perfect example is Corey Ladas’s Scrum-ban approach; a way to upgrade the default Scrum task board using Lean tools. Given the rising popularity of that article, I predict many Scrum-ban boards will be implemented by current Scrum practitioners. I expect some case studies to appear on Scrum-ban at Agile2009. Thanks Olav Maassen, a strong proponent of Kanban, a new stage has been added to Agile2009 for these cutting edge Lean practices. For more information, have a look at an in depth example is use of Kanban in the gaming industry.

Although there are different views on Lean within the Agile community, they have one thing in common, they all adopt only parts of Lean. One cause is the limited amount of books available on Lean Software Development. Of course the Poppendiecks have written great books on Lean Software Development, but a community needs more than one source of information. Books such as ‘The Toyota Way’ and ‘Lean Thinking’ describe the original Lean principles. When one reads these books, it becomes apparent that some key Lean concepts are ignored in software development.

David Binnerts pointed out the concept ‘standard work’ missing from Lean Software Development. Lean defines standard work as: ‘the current best practice’. Anyone performing the same task should follow the same procedure. This is the basis for ‘Kaizen’, the process of continuous improvement and refinement. Only with an established current practice can you improve that practice. Especially software developers have very limited experience with this amount of discipline and abolishment of variation. Perhaps David Anderson would want to to introduce this concept in software development using CMMI?

Dave Thomas and Alan Cooper describe the entire software development process more or less as a waterfall. According to Dave Thomas software is still hard to change once it is written, which makes Extreme Programming close to impossible for large projects. He claims the need for a design and architectural phase before actual implementation starts. This approach cuts the development part in two halves: the design and the implementation. Both this design and implementation phase would benefit greatly from a Lean approach. This is, however, not compatible to Scrum or XP and could be seen as un-Agile or labelled Big Design Up Front.

A concept like Standard Work doesn’t seem to fit the XP/Scrum organic self organization of teams. Whereas Scrum does not exclude this concept, as David Anderson states, Scrum could be viewed as the current best practice on which a team can improve further. Scrum, perhaps similar to CMMI level 2, a good baseline for further refinement and expansion into all areas of practice and organisation.

I admire David Anderson and Corey Landas for their unconventional thinking. A lot of new Lean concepts and practices are ready to enter the software development community. I hope Lean will be embraced fully, including the hard parts that require great discipline. I crave a new view on software development and a long term vision. A few months ago at Agile 2008 I speculated on a new hype that could surpass Agile, however I never expected it to come this quickly.

We’ve set up the Dutch Scrum group and named it nlscrum. We have already hosted our first meetup last month and it was a great success! We hope our next event will even draw a bigger crowd and more inspiring ideas!

The nlscrum community is now three months old and has over 50 members. Our first event was a few weeks ago, on the 3rd of September. About 25 nlscrum members attended our Open Space meetup. The event got a great rating of 4,5 out of 5! Most of the people were Scrum Masters or people starting with Scrum. The Open Space format needed some getting used to as it was new to most people, but after a while it turned out great. There were lots of discussion, sharing of experiences and new insights generated. I was glad to hear people thought is was a great gathering.

Discussing Scrum I noticed a few things. Some people were talking about doing multiple projects with one team. Apparently most Scrum customers aren’t used to feeding their teams with a single task. Serge has done some great work with multiple team setups, so he could help out there. Another thing that came up is the unique way we at Xebia combine project management with Scrum. We should talk about that more often as it will help people get a more mature Scrum process faster. Listening to the attendees I noticed the Product Owner role is still a bit of a mystery. I expect that role will get some extra attention next year.

That’s why our next meetup on November 4th will have a Product Ownership theme! Check the nlscrum.org website to apply and sign up for our next meeting. There are also pictures of the last meeting and a mailing list for burning Scrum questions. I’m curious what your experiences with Scrum are and I know we’ll be able to learn from sharing.

I attended this conference and gave a presentation together with Olav Maassen. I want to share some of the inspiring ideas and ‘vibes’ that I picked up at the conference.

On to something

Being amongst Agile people for a whole week gave me a very rich and inspiring feel for what’s going on in the software industry. The Agile alliance really shines this year because the conference hosted many different people and ideas, some of which are promoting Agile while others are pointing out shortcomings of Agile and some sessions even had nothing to do with Agile but were still filled with great ideas. I think I’ve picked up a few inspirational ideas that I want to explore further.
The thing that struck me most is the ‘vibe’ of where software development will see big improvements in the next years. Coincidentally my own presentation actually had similar points to the ones I picked up in other presentations. I was definitely on to something.

Apart from a few particular sessions that I’ll describe in later blogs, there are two main themes that I picked up at this conference that might not be obvious. One theme I like to call Agile+ and the other is summarized best as Iteration-1

Agile+

Agile+ for me is everything that I’ve heard at the conference that tries to improve Agile development beyond the current principles and practices. A few ideas were refinements of Agile practices while others extend to software development adding to the Agile foundation.

The principles of the theory of contraints will give an Agile team a new way of looking at their process and possible improvements. One shortcoming of Scrum and XP is that there are no limitations in for the team to increase their work-in-process. Using the Lean Kanban technique to push the cycle time down and revealing bottlenecks makes the self-organising aspect of Agile a much more disciplined and fruitful affair. One obvious practice that was mentioned is to always fix bugs immediately, don’t let the tester report a bug and then wait 2 days to fix it, but leave the feature in ‘testing’ until all bugs are actually fixed keeping the WIP low. This fits into a larger theme of applying Lean and TOC to software development to extend Agile with more discipline and insights. The Kanban system is a very concrete implementation of this. David Anderson gave a convincing argument for Kanban. As an early adopter I would like to see some whitepapers and handles to introduce Kanban in Agile projects. The most striking differences to classic Agile is the abandonment of iterations and planning sessions.

Iteration -1

Scott Ambler made a somewhat cynical observation that a lot of talks on Agile2008 are about what we ought to be doing in Agile projects (such as automated acceptance testing, pair programming etc.) but that actual experience show that some practices are actually not very popular although they are immensely popular as a topic of discussion (such as automated acceptance testing). Agile+ will bring more research and real stories on what’s really going on in projects so we can discuss reality and not an idealized version of reality. Now that Agile is entering the mainstream we’ll need more facts and figures to increase adoption than the anecdotal and inspiring stories we’ve used in the past.

The Iteration-1 came up a few times, even at other conferences. Scott Ambler mentioned it explicitly, but David Thomas, Allen Cooper and Jeff Patton also have some notion of it. To it’s core is the ‘could-be-controversial’ idea to not start developing software from the very first iteration. People like Scott are protesting the notion that your very first iteration of the project should start with coding (as XP and Scrum seem to promote). This might be a situation where Jeff Sutherland would say “I’m not sure on which Agile planet they are…” but I have experienced the pressure on Agile projects to fire up the IDE and start coding from the start. Now several people are proclaiming to take certain steps or phases before you start cranking out ‘potentially shippable products’. Now what you should do exactly varies from modelling to design, architecture, interaction design or building throw-away software.

Almost everyone agrees that you cannot build the right solution before you’ve seen the whole problem or scope of the project. This intrinsic problem might lead you to spend very little time on design or architecture because you don’t know what the best solution will be until you’re done. This is where Agile might overshoot in it’s focus on software and feedback. You can go around this smarter. You can use more than just ‘working software’ to find out what your customer really needs. Allen Cooper even says that even live software won’t give you the right feedback because people tend to have a bad idea what the really need even when they see it. So more time needs to be spend on discovering what features your users really need. So Iteration-1 starts before any coding starts. Scrum doesn’t describe what you do before the coding starts where except for ‘provide vision and backlog with features’. That gap needs to be filled.

I see one fundamental dilema with the Iteration-1, which is the Lean principles of minimising waste and work in progress. Design and architecture can be viewed as unvalidated artifacts that increase the cycle time of your features. On the other hand you can see a project as a discrete event that has a relative fixed set of problems to fix. Lean (and in some ways Scrum) seem to be geared more toward a continuous flow of features. This is great, but you’ll have to make sure that those features fit a coherent set, fit a coherent architecture and a coherent feature set. That’s where you’ll need a view of the whole system again. So if your starting a whole new project in a new context, you can’t start churning out features from the start, you’ll need some Iteration-1 (or -2, -3).

Conscious Development

I think a lot more attention will be spent on conscious preparation and applying requirements engineering, interaction design and architecting before the coding phase. This is of course a little like waterfall and a lot like the RUP iterations. The fact that people call it Iteration-1 shows they’re still a bit embarrassed trying to incorporate it with the Agile principles. Hopefully we’ll get over it and give it a proper name and give it a proper place in software development.

In the Lean Software Development method Scrum there are three roles: the Team, the Scrum Master and the Product Owner. In my experience the Product Owner role is by far the most confusing and hardest role to ‘get right’ and provokes the most discussion. Even the mere definition of what this person should do is under debate amongst most Scrum practitioners I’ve talked to. I want to discuss the origins of the Product Owner role and my experience in how (not) to fill this role, especially in companies that don’t do product development.

The mythical Product Owner

I’ve seen many flavors of Product Owners and none of them really worked as they should have. Actually, rumor has it that good Product Owners actually don’t exist. Now that’s something we should be frank about if that’s true. If the Product Owner is a combination of responsibilities that doesn’t work in practice, we should find some alternative. First, I’ll explain my experience so far.

Definition of the role

Scrum is based on best practices, no one ‘invented’ Scrum by merely theorizing about how the world should work. People like Jeff Sutherland and Ken Schwaber have done projects in the past that were successful and one of the major reasons for their success was the presence of one person who represented all customer interests to the team (later called the Product Owner). Ken Schwaber describes the product owner as ‘one person [that] is responsible for maintaining and sustaining the content and priority of a single Product Backlog’ Jeff Sutherland is more elaborate and lists all responsibilities of the product owner in his online book ‘The Scrum Papers’. Among others he adds the responsibility ‘[...] for the profitability of the product (ROI)’. The direct combination of the ROI and the features of the product are what Product Ownership is all about.

Different flavors

Keeping in mind what the product owner should be according to Scrum, I want to explain the different flavors of Product Owners I’ve come across. Their flavor was mostly defined by the person taking on Product Ownership and their ‘regular’ job.

PO the Product Manager
In product development companies, such as famous Scrum companies like PatientKeeper and Planon, there is usually a role called Product Manager. A Product Manager can be the Product Owner without any issues because they are almost synonymous. Scrum gives the Product Manager a specific way of controlling his product by use of the Product Backlog. The only real issue that I’ve seen is that product managers tend to push down on the teams to deliver, which is considered a bad practice and eventually decreased productivity. Product Manager ‘only’ have to learn empirical management to be good Product Owners.

PO the Project Manager
In most projects I’ve worked in, the project manager does the planning of activities. If he gets the Product Owner role, he usually approaches the backlog from a planning perspective. That means he’ll decide what goes into what sprint based on external dependencies and availability of staff etc. Most project managers are actually not responsible for the profitability of the project or the budget. The PM makes the plan, but the Project Board approves the plan and budget. If the project goes over it’s deadline or budget the Project Board is accountable (if the PM gave ample warnings). The main problem is that work should not flow from managers but directly from stakeholders to developers because a manager is not the customer and usually lacks the business knowledge to make the right decisions. A project manager would actually have to be made accountable for the budget and profitability to be a good Product Owner.

PO the functional/information analyst
For most teams this sounds like the ideal product owner. An information analyst usually has in depth knowledge on what the customer needs. The information analysts I’ve worked with were good at structuring information and conveying it to the developers. Although very good for the productivity, an information analyst is not the same thing as a Product Owner. The analyst usually has ‘feature perspective’: what should the product do. His main competence is getting the requirements and wishes from the (potential) users of the system. If left unmanaged he’ll try to please the customer by implementing everything the customer asks for.
Implementing all requirements sounds good, but few projects have enough resources to do that, that’s why you need to prioritize features. I haven’t seen information analysts do this very well because the budget was not their responsibility. The analyst might work very closely with the product owner to prepare coming Sprints but he doesn’t actually need the Product Owner for that if the Product Backlog is in good shape. In any case an information analyst is a very valuable team member, not a Product Owner.

PO the Release Manager
A somewhat ambiguous term ‘release manager’, but it’s best explained as a coordinating planning and resource manager that plans work to be done and selects team members to do it. He also reports the status of work to stakeholders. In some ways the release manager role sounds a bit like the Product Owner role, they both feed work to the team. However, there were a few issues with this specific release manager as Product Owner. First of all, the release manager only planned work for one ‘type’ of developers (J2EE, C++ or .Net etc.) which means that features had already been split up into work packages for each competence. This makes prioritization an impossible task because the link between the work packages and the actual features were missing. The distance between the business case and stakeholders and the release managers was simply to great to make any real decisions and it wasn’t allowed to drop features to meet the schedule. So these release managers were Product Owner for one reason, we were doing Scrum and we needed someone (anyone?) to fill that role because it was in the Scrum book.

PO the Unit Manager
In one of my projects, a unit manager (manager of a business unit within an IT organization) took on the product owner role an in-house project. The main focus of a business unit manager is his people and because he knew Scrum he had no problem facilitating the team and giving them trust and responsibility. But that’s not the main responsibility of the Product Owner, that’s being accountable for the outcome of the project.
Getting the accountability right in an in-house project is perhaps even harder then when there’s a clear customer-vendor relationship. In this case team members were also stakeholders and the unit manager and stakeholders also wanted to help with development (are you still with me?). The main problem was accountability hadn’t been transfered explicitly to the Product Owner. The executive that controlled the budget had little control over the project and thus we fell into the age old project-trap where the people with the money ask “where is my money going?” The Unit Manager didn’t get to spend the money as he saw fit and didn’t take over responsibility for the success of the project, which left the Executive as the ‘hidden’ Product Owner.

The ‘right’ Product Owner

Although I haven’t seen the role filled correctly, I do see the need the Product Owner role is intended to fulfill in Agile projects. The big word here is Business Case. The business case describes the benefits of the deliverables of the project, for instance: “If we implement software product x, we’ll save x amount of money per year”. Executives love Business Case driven development and that’s why the Product Owner should steer the project using the business case (perhaps we should call him ‘Business Case Owner’?). The reverse is also true, if your Product Owner isn’t accountable for realizing the Business Case, he’s not your real Product Owner. But if you can transfer accountability to the product owner, what kind of competences does the Product Owner need to posses to perform Business Case driven steering?
Business Case Value
He needs to know which features add most value to the business case. If time saving is the main goal of the product, measurable time-saving features are valued higher than (for instance) usability features or product maintenance features.
Financial
He needs to know how much money a feature will cost and how much it will deliver. Having feature set X will increase our market share by Y. He needs to know how much to spend on each feature set and be able to drop or simplify features to match the budget.
Some domain knowledge
The product owner needs some domain knowledge so he can decide on what the stakeholders are talking about. Combining high level knowledge of features coupled with owning the business case is the main benefit of the role.
Time
One often discussed topic is the availability of the Product Owner. If you look at the responsibilities, he doesn’t have to be available full-time. If the product backlog is in good shape and priorities don’t change often the team can refine and implement the backlog items without the Product Owner.

The impossible job?

Now for the big problem: reality. Anyone can describe what a good Product Owner should be and do (I just did), but that doesn’t make it a reality. There is a fundamental problem with the Scrum Product Owner role outside of product development companies: good Product Owners are too rare. Most Scrum experts actually admit that a good Product Owner is a rare phenomenon.
One of the great selling arguments of Scrum is that it’s a lightweight process, some might even call it a process framework. That’s a good thing because that means you can start using Scrum quickly and then fine tune the actual process within the Scrum framework. However, the Product Owner role hinders this easy implementation of the framework. I can’t start up the customer-project feedback cycle immediately because in my experience the demands for the Product Owner role are too high.

Conclusion

I’ve explained when the Product Owner role didn’t work as it should have and also what a good Product Owner should be concerned with to maximize the project effectiveness by focussing on the business value of it’s features. I conclude that the role is hard to fill in the right way which makes Scrum hard to kick-start and makes the process feel either broken or too heavy.
Perhaps we need a special ‘non-product-development’ version of Scrum? Or redefine the Product Owner role to fit large organizations so that we can start the process immediately and then gradually move towards the ultimate vision of true collaboration between the business and development.

Let’s imagine the project has just started, the business has come in with a request and they want their problem solved. The competition has launched a new product or is offering their services for a lower price, so things need to change. Let’s say their problem is ‘finding information on customers’. When the business wants information on a customer, it takes forever to find all information. They want an automated solution that can satisfy their information needs quickly and accurately. Sounds like a familiar problem? Let’s look at our team to see how they handle this. They’re having a meeting on ‘process and tools’, asking themselves ‘how can we tackle this?’ They want to do a good job, letting the business know how the problem needs to be solved, coming up with answers and solutions. There is clearly a positive vibe in the team, you can feel the ‘we’re going to get it right this time’ atmosphere. After a few weeks of solid discussion and studying of the business case they come up with a plan. The business is pleased, this looks like a real plan. What are they waiting for? Let’s do this thing! So after the business has given a ‘go’ they start making plans for next year, ‘we’ll have this new search capabilities, how can we turn that into profit for our business?’ The business starts to get exited as well, the goal of any IT project.

So next step, the design. It’s gonna be a big one, this is a complex problem which needs some complex solutions and good thinking. Thinking caps on and let’s make that design. All limits are off, out of the box thinking is what we need. Someone says: ‘What if we use this new technology? We’ll be able to roll out new solutions in no time, the business will be so pleased’. That’s what I call focus on business value! We’ve got some enthusiastic people on the team. The design is coming along nicely, after only a few weeks the outline is getting visible, without being limited by details the team can paint a perfect picture. Discussing all kinds of issues, thinking of possible problems (such as error handling) AND their solution (a error reporting tool or framework will do the trick) they work through all the details. It’s not easy, but after a few months they finish the design. A job well done!

Now it’s time to get some more support for the project, more people need to get involved. The business needs to be updated of our design as well, we want to include them in the process, we’ve got feedback along the way but now they can see the finished design. If we present it well they’ll come with good feedback and perhaps even new ideas. That will give the project a new boost… Luckily, the presentation goes as planned, the business is pleased. If it all works as designed they’ll be competing like crazy in a few months…

This is where the implementation cycle starts and my blog ends. I won’t go into further details, you might have experience with this kind of projects and fill in the rest yourself. But let’s think about what the team and the business went through. BUFD allows for good communication, working as a team, sharing experience, fixing problems, involving the business, thinking about business value etc. With the added benefit of setting high ambitions and creating an imaginary product and business process that makes everyone feel good. People like imagining things, thinking big, thinking of future issues and coming up with their solutions by discussing different options. Plus, the development phase is tough, so good preparation increases confidence throughout the company. BUFD gives you that confidence…

If people want to stop doing BUFD, where will they get our sense of security? Can they keep using their imagination and expertise to reach that state of perfection that they’re used to work towards? If we want to improve the way people do IT projects, we’ll have to understand their current motivation for doing it waterfall, only then can we make the first steps towards change.

There are some scrum checklists out there: Scrum Rules Cheat Sheet, Scrum checklist. I would like to add another list. My list is not so much about the practices of scrum, but focusses more on the goals of scrum (such as communication, trust, teamwork). The list contains questions you can ask the team. Try to answer all questions within short time (say half an hour) by looking at the work space and talking to the team. If you need more time or cannot answer all questions, you might have some things to discuss during the next retrospective. I hope it will get you and your team thinking about areas of improvement.

Scrum Questions

Try to answer the following questions by looking at the whiteboards:
- When will the iteration be finished, how’s it going?
- If it’s not finished in time, what are the impediments blocking the team?
- When will the next milestone/release be finished?

Try to answer the following question by looking at the product backlog?
- What would be the next item to pick if the current iteration is done?
- Where are the features/tasks that don’t have a priority (yet)?
- Which stakeholders would understand the items on the backlog, which wouldn’t?

Try to answer the following question by looking at the team at work?
- Is the energy level high?
- Which people belong to the same team?

Try to have the following questions answered by talking to the team.
- Who are the stakeholders for the project?
- When was the last communication with a big group or all of the stakeholders on the project status, less than a month?
- When was the last time stakeholders gave feedback on work that was delivered, less than a month?

Scrum practices
There are a few things Scrum enforces that aren’t always embraced by the development team. The time that Scrum takes for meetings such as the stand-up and sprint review are considered overhead. It’s hard to motivate people to stop and think about their process or communicate about their issues when they’re thinking ‘how to get out of this meeting’. It’s also quite hard for people not to think about all the stuff that has always gone wrong but only the trouble you’ve had in the previous sprint. Complaining about problems that are out of your scope and influence is not productive, but focussing on just a few weeks takes more effort than I expected.

Take action
In Scrum decisions are made quickly while actively seeking feedback on the result. This can also be a disruption in the way people are used to work. Decisions are usually made very carefully, with lots of discussion on the pros and cons. In Scrum we assume that decisions should be made quickly to keep the project going and in most cases the end result is acceptable. Stopping developers doing research on different options and creating proof of concepts feels like imposing a restriction on how they want to work. I think Scrum allows for a lot of freedom, but not the freedom to waste time dwelling on options.

Product owner decides
The hardest one for me is the decision on technical issues. The product owner decides on the priorities, even on taks that the developers come up with. The team has the responsibility to do the work in the way they seem fit, keeping up quality standards but other stuff such as ‘we should automate all testing’ is something the product owner can give lower priority to. ‘Creating a test script for feature X’ might be less ambitious and get a higher priority or can even be seen as a necessary step to complete a feature. This haggle between the product owner and the team is a new phenomenon, which could end in frustration because developers aren’t given to the time to make things ‘perfect’. Everything should be driven by business goals and sometimes that leaves no room for optimization or tweaking.

Listen to the team
So what can the scrum master do? First of all, listen to the team. Most of the time the frustration and complaints have a serious cause. Challenge the team to come up with things they do to deal with those causes. But some things in Scrum will just take getting used to, some things might never feel right for developers. I think that, when Scrum has been introduced, working together as a team and getting the satisfaction from getting things done and pleasing your stakeholders is more than enough reward to keep the team motivated.

In Agile projects there are a two constraints that apply to the ‘traditional’ way acceptance tests are performed: test first and agile (flexible) test cases. When working with dedicated testers, the developers need to work together with them as a single team. Using the ‘test-first’ approach, you need the input from the tester before you can start coding, otherwise you won’t know when your work does what it needs to. One other problem that both developers and testers face is responding to changes. When the customer wants a new feature, you can’t reply: “It was never build to do that!”. We’re agile, so we’ll refactor the code if needed. Changes also apply to tests, requirements change and the software changes (database changes, user interface changes, etc.). So the tester needs to be able to deal with those changes.

There are a few things we can tackle. The magic word here is ‘Fitnesse’. Fitnesse allows you to combine test case specification and execution on one page. This allows for very smart test cases, you could have something as simple as:

My test data:

The test:

You can actually ‘run’ this table and using some glue code (called Fixtures) you can actually test your application for searching people. This kind of test case format doesn’t require any knowledge of the inner workings of the application. Whether it’s a swing or web application, uses a database or a mainframe to store information. The fixture will make sure the test will work. That makes it more readable and agile because I can refactor my application and change the way we store data (let’s stop using that mainframe) and as long as the fixture is refactored too, the test is still executable.

That’s how we like to test, leaving the implementation details out of the test and define them on a functional level. We implement our fixtures using selenium so we can run the test directly in a web browser (such as firefox).

Although we have been working using this approach for quite some time now, there are still a few problems we haven’t quite solved yet. User acceptance testing is about proving that the application works exactly as it should. The tester needs to prove that no (serious) bugs exist, by testing complete scenarios (for example test the whole process of ordering a product, from registration to payment) but also test corner cases. But there is a problem with all these test cases, you need to change them when the application changes. After about a year of development, you’ll acquire hundreds of test cases. Suppose the registration process changes, and you used registration in dozens of cases, how do you change all of them?

One way to minimize impact of changes is to create the idea of unit testing in acceptance testing. Unit testing means you test one unit at a time, when unrelated units change, your test won’t break (because it wasn’t testing those). The same could apply to User Interface tests, you could test the registration part in many different ways, but when testing other parts of the system you should just be able to assume there is a user that can log in (again something the fixture can solve). This user could be specified as a default application user (a ‘John Doe’). Now you don’t have to go through the whole registration process, just to be able to log in to the application. Our test cases (for our web shop application) can now be written like this: “John searches for ‘ipod’ and finds these items…” You could call this a Domain Specific Language specific for testing user stories. You can have very powerful tests this way.

Although Fitnesse is a good tool for Agile testing, doing Acceptance Testing is always demanding and maybe more so when doing it Agile. Most customers use professional testers, but they are usually not used to Agile development. Often they rely on lots of excel sheets, lots of specifications and sometimes even loads of SQL scripts for their input-output tests. A lot of knowledge about the application is spread and duplicated across all those files. Helping them automate their tests in a more expressive and condensed way will keep the tests easy to change and readable by everyone. However, actually finding the most efficient way to give the testers the insight and control they need whilst staying Agile remains a challenge.