How you could deal with early estimations

Recently people have been asking me how to deal with so-called ‘expert estimations’ in Agile development. In most organisations where IT is seen as a supplier or cost centre, the business wants to know the costs and the duration of a project before it decides to fund it. This is of course perfectly normal!

The poor IT department is asked to do an ‘expert estimation’ based on the available vision, requirements and any other available information. The estimation is expected to be quite accurate with e.g. a max -10% to +10% deviation. So the IT department adds the necessary buffers and slack to the estimation. As a result the project plan is probably longer then necessary which results in longer projects and less productivity thanks to Parkinson’s Law. The project will also unnecessary claim personnel and other scarce resources for longer periods complicating their use by other projects. Task switching and hand-offs now become a necessity as people must work on multiple projects. It often also results in a project to not start at all thanks to the overestimation!

 So, how could we do this in Agile?

 Well…, what some people do not seem to realize is that in Agile we also provide estimates upfront. In Scrum e.g. we have the estimation meetings where the product backlog is estimated. We estimate just enough to be able to make the ‘right’ decision. We acknowledge that in the beginning of a project, when we know least about it, the estimates could be very inaccurate. We keep on estimating throughout the project increasing the accuracy of our estimations as we learn more about the project. We measure our progress based on actual working features and value added. This enables the business to get valuable estimation and planning info as early as possible to make the ‘right’ decision, which could be to stop the project! We use a project baseline that is based on actual data and progress. If we have 1000 points of estimated work, we work with 2 week iterations and we must be complete in 20 weeks then we must burn 100 points every iteration. This becomes our baseline and is used to measure our schedule and budget variance. We track features completed vs. features remaining, work in progress, feature cycle time and client value added. In Agile we do a lot more planning and we do it throughout the project.

We use the initial estimation to make the funding decision! We then have our estimated schedule, budget and functionality. After the decision to fund the project is made, we use the mentioned metrics and techniques to steer the project and track against the initial schedule and cost estimation. We re-estimate and re-plan based on real progress and provide the business with the most accurate information as quickly as possible.

The end of the ‘Internet’ testers

In the days of waterfall project the testers did not have anything to do during the first half of a project. During this period they would spent most of their time surfing the net and rewriting their test plans. Nowadays with cross functional teams the testers play a significant role right from the beginning of the project. 

The role of a tester is not just testing anymore. An agile tester helps the team figure out what needs to be delivered at the end of a sprint. He plays an important role in clarifying the user stories and establishing a common understanding on the requirements within the team. During sprint planning the tester helps to clarify the user stories by also paying attention to things that could go wrong (Developers often have the tendency to see only the happy flow). Next to that testers work on requirement examples prior to sprint planning together with the requirements people to start the feedback early on. During the sprint the testers continuously provide feedback to the rest of the team to ensure the right thing is build correctly the first time.

When the team finishes a story during the sprint, a tester can have a feedback session with the product owner by demonstrating the user story and showing that the acceptance criteria are met. This is specially valuable in case the product owner is discovering what it really needs! In that case the acceptance criteria or the accompanying specifications are vague and the team helps the product owner figure out what he wants. Based on what he sees he gets a better understanding on what he really needs. It’s like when you want to buy a table. You know what a table looks like, but you can’t exactly specify the table you want. That’s why you go visit stores to see various tables. One table you see helps you to decide on the table size, while another helps you decide on the color and yet another helps you see the style and material you like. By having seen these examples you steadily get a clearer and more accurate picture of what it is you really want.

So for the testers there is no more laying back during the early stages of the project, but instead being part of the team right away and working hard to help the team achieve its sprint goal.

Roles in Java using ObjectTeams

I’ve been testing ObjectTeams for a while now and think its a really cool way for using roles in the Java language. A role is a set of attributes and behavior a object can assume temporarily in a certain context. It’s like an actor behaving according to the film script. The actor plays the role as described in the script as long as he is shooting the film. After that he returns to be himself again.

Roles can help you in achieving a strict separation of concerns. This is because roles let you encapsulate context specific behavior in a role removing it from the class itself. In a collaboration you can have multiple roles working together to achieve some functionality. An example of a collaboration could be a car race. The Race collaboration exposes the role of a RaceCar for cars that want to participate in the race. A car object that assumes the RaceCar role will get additional state and behavior defined in the role RaceCar. These could be things like laps to go and car number. The Race collaboration itself can also have state like e.g. the participating race cars and the laps to go untill the race ends.

ObjectTeams is an extension to the Java language. It introduces some new language constructs that make it possible to program using roles. A collaboration is represented by a team and declared using the team keyword. Within the team you can define roles and their interaction. You can express that objects of a certain class will play a certain role using the playedBy keyword. As a result objects can be extend at run-tme with role specific behavior and state.

See below an implemtation of the SubjectObserver pattern in ObjectTeams.

public abstract team class SubjectObserver {
    …
    protected abstract class Subject {
        private LinkedList<Observer> observers = …
        public void attachObserver (Observer o) {…}
        ...
        public void notify() {
            for (Observer observer : observers)
                observer.update(this);
        }
}

    protected abstract class Observer {
        abstract void update(Subject s);
}
}

You see that we have a abstract team SubjectObserver that defines the roles of Subject and Observer. Lets assume that we have a TV and a Screen that needs to be updated when the TV changes state. We have to let TV play the role of Subject and Screen play the role of Observer.

public team class ObservingGraphical extends SubjectObserver {
    protected class Subject playedBy TV {
           notify <- after setPrice;
      }

    protected class ScreenObserver extends Observer playedBy Screen {
        update -> redraw;
}
…
}

We see that team ObservingGraphical extends SubjectObserver. Because it uses the same role name for Subject as its base, this role is implicitly extended using the same name. You can also see the use of playedBy keyword.

To couple the objects and roles the so called callin and callout statements are used. Using callin statement ‘notify <- after setPrice; ‘ you state that after method ’setPrice’ is called on TV, method ‘notify’ of Subject should be called. Using callout statement ‘update -> redraw;’ a call of the ‘update’ method on Observer is mapped to method ‘redraw’ on Screen.

How to use the collaboration and its roles is shown below

final ObservingGraphical observingGrph = new ObservingGraphical();
TV tv = new TV();
Screen screen = new Screen();
within(observingGrph) {
observingGrph.attachSubjectObserver(tv, screen);
tv.setPrice(1000);
}

The interesting part is the within statement. It defines that the role specific behavior is active. During the statement the objects TV and Screen are extended with role specific behavior. After the within statement they are back to normal again.

References

[1] E. Gamma et al (1994). Design Patterns: Elements of Reusable Object-Oriented Software.
[2] Edsger W.Dijkstra (1974).  HYPERLINK “http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html” http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html.
[3] Robert C. Martin (2002). Agile Software Development: Principles, Patterns, and Practices.
[4] ObjectTeams.  HYPERLINK “http://www.objectteams.org” http://www.objectteams.org/
[5] ObjectTeams language definition.  HYPERLINK “http://www.objectteams.org/def/1.2/index.html” http://www.objectteams.org/def/1.2/index.html.
[6] Bertrand Meyer (1997). Object-Oriented Software Construction, Second Edition.
[7] Matteo Baldoni et el. The Interplay between Relationships, Roles and Objects.
[8] Trygve Reenskaug, Role Modeling.  HYPERLINK “http://folk.uio.no/trygver/themes/roles/roles-index.html” http://folk.uio.no/trygver/themes/roles/roles-index.html.

Prioritizing the backlog on Quality

After my talk at JFall about EasyB and Agile requirements I had a discussion with a very respectful guy about some things I said during my talk. The discussion was about whether building up quality over time is a good or a bad thing!

In my talk I stated that some features like for example an engine, brakes and a steering wheel are all MUST if you are building a car.  So it’s silly to prioritize them. As far as I know, you just don’t have a car if you don’t have these features. We all know that in order to have the most business value when the budget runs out or the deadline is there, you should prioritize your backlog! So in this case, what are you going to prioritize…..?

Well, it’s real obvious, you can prioritize on quality. I am not talking about software quality here, I am talking about the quality of a feature. If we define that horse power is a quality of an engine then an engine of 400 horse power, is of higher quality then an engine of 100 horse power. The difference in this quality is expressed as a difference in time and cost to develop! So, it’s better to build a engine of 100 horse power, and the rest of the MUST things at lower quality first so you have at least a car.
Once you have that you can start building up feature quality and see how much luxury you can add within the given time and budget. If you build your features up to the most quality one by one, chances are you’ll end up with a car having 400 horse power and super brakes but no steering wheel!

In my opinion we were arguing about the definition of quality. While I was talking about feature quality, I guess he was talking about the quality of the product you deliver at the end of a sprint! In almost every situation you want your sprint result to be of the highest possible quality ofcourse. That’s what Lean and Scrum tells us right!

My Talks

LightWeight Grids With Terracotta: At the NL JUG in November 2007

LightWeight Grids With Terracotta: At the PT JUG on March 2008

Top 9 Challenges of Adopting Scrum: At the PT ScrumAlliance User Group in Lisbon on September 2008

Challenges of Adopting Scrum: At the XP Days Benelux in November 2008

Easy Requirements By Example: At the NL JUG in November 2008

Scrum at Large Enterprise Case Study: At the NLSrum in March 2009

My Papers

Lightweight Grids with Terracotta in Java Magazine, 2007

Top 9 challenges of adopting Scrum in Agile Journal, 2008

Top challenges of adopting Scrum in JavaMagazine, 2008

Objects and Roles with Java in JavaMagazine. 2009

Top 9 challenges of adopting Scrum

Scrum is a simple process, but can be quite challenging to implement. In a series of articles on AgileJournal myself and my colleague Eelco Gravendeel will discuss the top 9 challenges we encountered during various Scrum adoptions.

You can read the first part of the series at  Top 9 challenges of adopting Scrum.

You can read the second part of the series at Top 9 challenages of adopting Scrum part 2.

The third and final part is at Top 9 challenges of adopting Scrum part 3.

You can also see a brief summary at InfoQ see challenges of adopting scrum.

Agile architecture metrics

In developing software there is a need for communicating ideas and chosen directions among team members and customers alike. Some sort of overall view and common vocabulary about the domain provides understanding of the system and is a basis for discussion. Software architecture provides such a “gestalt perspective” and is therefore very useful in any but trivial software development effort. In agile methods there is no BUFD, but how do you know you are doing enough architecture?

Lets take a quick look at what three well known methods have to say about architecture.

eXtreme Programming

In XP architecture is just as important as in any other software project [Beck00: pp 113]. XP used the notion of the system metaphor to cope with software architecture up front. The system metaphor is used to create the big picture of the system, the vision of the system’s components and how they work. About 8 years ago Kent Beck defined it as:

“System Metaphor - A story that everyone – customers, programmers, and managers – can tell about how the system works.” [Beck00: pp. 179]

You can learn about the problem at hand by using spikes. The spikes drive the System Metaphor. So even in XP you can have initial “architectural” work to set the baseline for understanding, communication and vision. Kent Beck was quoted saying “The first iteration must be a functioning skeleton of the system as a whole.” [Wake02: pp78].

Unified Process (they say it’s agile)

The UP creates high level architecture in the inception phase. It then creates an appropriate executable architecture during the elaboration phase. The architecture tackles risks, develops a common understanding and is the basis for identifying reuse and for further development during the construction phase [Kroll03: pp120].

Feature Driven Development

FDD suggests that architecture could evolve in parallel during the Develop an Overall Model, Build a Features List and Plan by Feature processes. The goal is to have enough architecture ready to start iterating though the Design by Feature and Build By Feature processes [Palmer02: pp. 204]. During the first iterations a lot is learned about the system and the architecture keeps evolving until it becomes more or less stable during the project.

The common thing here is that they all do upfront work prior to development to establish common understanding about the system domain and functionality. UP does a lot, FDD does less and XP does the absolute minimum. The effort for getting the big picture right is higher initially and then decreases as iterations and increments pass. In agile projects you keep on learning and adapting and therefore do not stop doing architecture work until the end of the project.

So all this would mean that in a healthy agile project you will see something like depicted in the figure below.

Initially you spend more effort on architecture compared to developing features. The amount of architectural work will decrease over time but will only be done when the project is finished. The effort spend on features will increase. So you should also see a steady increase in the number of Running Tested Features http://www.xprogramming.com/xpmag/jatRtsMetric.htm.

By defining some architecture upfront you optimize your throughput not at the level of the current iteration but at the release level as discussed in YAGNI by the book.

References

[Beck00] Beck, Kent. Extreme Programming explained.

Addison-Wesley. 2000.

[Beck01] Beck, Kent and Martin Fowler. Planning Extreme Programming.

Addison-Wesley. 2001.

[Wake02] Wake, William C. Extreme Programming Explained.

Addison-Wesley. 2002.

[Palmer02] Palmer, Stephan. Feauture Driven Development.

Prinice Hall. 2002.

[Kroll03] Kroll Per and Philippe Kruchten. The Rational Unified Process Made Easy.

Addison-Wesley. 2003.

YAGNI by the Book

I recently attended a workshop on Agile architecture by James Coplien. He made some very interesting remarks. He claims that your domain architecture,”what the system is”, is relatively stable. The domain of a bank or insurance company will not change that rapidly! Things that do change have to do with “what the system does”. The user stories and the user interface just to name two. He reasoned that you are creating “knowledge debt” if you know something but do not act upon it.

He further claims that doing too little architecture up front gets you into trouble around the third month of an agile project. To cope with new requirements and gained knowledge about the problem domain a lot of ‘refactoring’ or re-architecting as he calls it is needed. As a result your overall velocity goes down!

I personally experienced various projects that had to do excessive refactoring as sprints passed. The refactorings had a severe impact on velocity. In every one of these projects the misapplication of the Simple Design and YAGNI principle was part of the cause. The misapplication is in applying it to the letter. If you do that you are saying, “I focus only on what is valuable in the present and I assume I know nothing about the future because nothing is certain”.

The good thing is that you CAN know things about the future pretty accurately. There are always things you know upfront and that are relatively stable. “You know the sun will rise tomorrow”! It may not…. but I’ll bet you it will. If you are building a family car you know that it will require brakes. Putting in a steering wheel is not enough.

So if you apply YAGNI to the letter you are playing stoopid. You should use your knowledge about probable future things and act upon it. If this means putting in flexibility into the system this iteration because in the next you WILL need it, then just do it. I am not saying you should build functionality in the present it if it’s not part of the current iteration. I am just saying that you should always keep the design as good as it can be. Putting in flexibility for a highly probable feature in the near future sounds like good design to me!

Should you put all work on the product backlog?

In a particular project I was involved in the stakeholders and the product owner was not interested in the technical tasks the team was working on. Technical tasks could be anything from setting up environments to software architecture work. The stakeholders were only interested in the user stories the team was working on and the progress in terms of completed user stories. The product owner actually told the team to stop putting technical tasks on the backlog because they could not relate to them and therefore could not assess their value or even prioritize them. Of course you write as much of the technical work in terms of a user story. But there are always technical tasks you need to do that are e.g. needed for multiple user stories.

So in the end the team satisfied the product owner and ended up with a product backlog with just user stories!

So where do you put all this technical work?
First of all, the team estimated the user stories without any assumption that any other stories or any technical tasks are already done. This approach improves user story independence and provides the product owner with the greatest flexibility on prioritizing the backlog. Because there were only user stories on the product backlog it also helped the team focus on developing only that part of the software architecture they actually need in order to realize the user stories at hand. It acts as a natural guidance for the team in applying the principle of Simple Design and YAGNI. So the technical work gets divided over the user stories and emerges as tasks on the sprint backlog only when and to the extend that they are really needed.

You might think that the big downside to this approach is that it hides work and does not provide the most transparency. I would argue that because architectural tasks pop up in the sprint backlog you are being transparent to the people who are interested in technical tasks, without confusing the ones who are not.

As a result of all this the team’s velocity is lower in early sprints and increases and eventually stabilizes over time because it benefits of the architectural work already done. It’s obvious that your velocity will increase once you have stable software architecture because you have to do less work.So it’s probably the case that stable software architecture gives you higher velocity. The interesting question is ‘how much upfront architecture do you need?’

This experience showed me the being transparent as a team is very important but in order to be so you don’t need to write ‘all’ your work on the product backlog.

User story driven performance testing

Quite often performance testing is only done after the system is developed and is in it’s acceptance phase. Of course this can give you some unpleasant surprises. You would like to get feedback on performance issues as quickly as possible.

We could tackle part of this problem by doing performance testing each iteration and by making performance testing part of the daily or continues build. To make the test results most valuable, the test environment should resemble the production environment as much as possible. I know that it’s very hard to realize this especially in big projects at big companies. But even if you cannot have a representative environment, doing performance testing each iteration can give you some good insights into performance trends during development. If some piece of functionality is getting slower and slower it could indicate that there are performance issues. Having insights in these trends gives you the possibility to investigate these possible performance issues early on while fixing them is still cheap.

JUnitPerf is a library for decorating JUnit tests to measure the performance of functionality contained within existing JUnit tests. You can write TimedTests that test if a JUnit test finishes within a certain time. You can also write a LoadTest that lets you measure the elapsed time under concurrent use. Because it is based on the Decorator pattern you can easily combine load en timed tests to create more complicated ones.

Using JUnitPerf can give you trends based on written JUnit tests. But a JUnit test is not that suitable for performance testing. A JUnit test fixture can have a number of various tests including expected failures etc. What would really be interesting is measuring performance of functionality that is valuable to a system user. You would like use your user story scenarios not only for acceptance testing of functionality but also for performance measurement.

The idea is to use a BDD framework like easyb for writing your acceptance test scenarios for a iteration as I explained in Easy Requirements by Example. The scenarios are complete pieces of user valued functionality and so are a perfect candidate for performance testing.

It would be great if you could write something like this in easyb for measuring performance of individual steps;

performancetest {
given “scenario X”, {
Scenario x = new Scenario(”X.groovy”);
}
when “load is generated by 10 persons”, {
x.load 10
}
then “measure individual step performance”, {
x.measureSteps
x.start
}
}

or the following for a timedtest under certain load;

performancetest {
given “scenario X”, {
when “load is generated by 10 persons”, {
x.load 10
}
then “response time should less then 3 seconds”, {
x.start
x.responseTime.lessThan 3
}
}

or just for a timed test as

performancetest {
given“scenario X”, {
when “load is generated by 1 person”, {
x.load 1
}
then “measure end to end performance”, {
x.measureEndToEnd
x.start
}
}

I am currently working on getting this done in easyb. I’ll write about it in the next weeks.