If results are not the point - then what is?



March 10. we've arranged a talk by Lean Software pioneer Mary Poppendieck at IT-Universitetet in Copenhagen. Check your calendar and sign up - It's free! Check details here (in danish)

As you may now Mary and Tom Poppendieck has recently published their third book 'Leading Lean Software Development: Results are not the point'. Check it out at Amazon.



Mary and Tom is also doing a 2-day workshop i Copenhagen March 11 and 12. Check details here.

We hope to meet you there.
By Sune Gynthersen

Games is a big topic at Agile 2009. Not computer games, but participatory, experential learning games where the players learn about the dynamics of organizations and Agile software development. I've been to several great sessions where games played main role, e.g. The Bottleneck Game and Applying Systems Thinking for Organizations through Play.

My take on the popularity of experential learning games at the conference is that we've tried for some time with all the hard-hitting, rational arguments for why Agile is a better way of developing software but those arguments fall short with people that are deeply rooted in other ways of seeing the world. To be able to reach out to those people the Agile community needs ways to provide those people with experiences that will convince both intellectually and emotionally. Experiental learning games is a great way of doing that. And fun too.

By Thomas Blomseth

As previously reported here we are establishing a new kind of contract for developing software solutions, currently dubbed the "Collaborative Agile Contract". In short this contract introduces fairness to ensure that both risks and gains are shared between customer and supplier. This ensures incentives for both parties to reach the right solution as fast as possible.

On the front page of todays Wall Street Journal is an article 'Billable Hour' Under Attack. This article focus on the trend in relationships between clients and law firms to find better kinds of contract than "payed by the hour", exemplified with the following quote:

"Pfizer could have demanded a discount from firm's hourly rates, Ms. Schulman said, but she hopes for a shift to a system that encourages firms to work more collaboratively with Pfizer."

It seems that the collaborative agile contract might be useful also outside the software business.
agile kontrakter

By Lars Thorup

Here is a nice blog-entry about what you can learn when you actually engage with your endusers.

Gemba in the virtual world



By Bent Jensen

I first came across the term vertical slice when I was in the video games industry. Trying to raise capital for our game, we were told by venture capitalists that they needed to see a vertical slice in order to assess our concept. That meant a small version of our game with just a little bit of everything. You should be able to see the technology, the artwork, audio, game design and all. I am not sure where the term originates from, but it is easy to realize what it means. If you consider a product to be composed of layers, the vertical slice represents a little bit of each layer.
This blog is called The Vertical Slice for a reason. While there is great focus on prioritizing in agile development, the emphasis is often in the concept of "business value". Which is a very sound focus compared to say, premature optimization or writing a system that is unnecessarily generic. However, focusing on vertical slices is equally important. As my colleague Lars suggested recently, the term breadth-first development is perhaps even more descriptive. If you consider the product to be a tree of increasingly detailed features, you want to start at the top and move into the details at all levels at the same time.
There is a consequence to this: you run into a lot of problems at the very start. A project that we are currently working with includes a web-frontend, a database layer and a reporting system that have all given us different kinds of problems. Other teams might have focused on getting one part working before moving on to the others but in the spirit of breadth-first, we wanted to work a little bit with all of them. That way, we don't run off on tangents in one of the layers, which might turn out to be unfeasible or simply incompatible with the rest of the environment.

By Kristian Dupont

Recently peterstev reported on, 10 Contracts for your next Agile Software Project.

In BestBrains we now have experience from two commercial projects using a new kind of agile contract.

We want to create contracts where risk is shared fairly between customer and supplier and where likewise benefit is shared fairly. Based on our experiences we have arrived at a contract model that has proven to achieve this result. We call this the collaborative agile contract.

The main mechanism of the contract is to delay some of the payment until a certain criteria has been reached. We do not use a date as this criteria which otherwise seems to be common. Rather we want a criteria that tells when we have a situation where the customer is getting value from the software. There is generally a mutual interest of arriving at this situation as quickly as possible. Effectiveness and creativity from the supplier will be rewarded. And the customer will be careful when deciding what features are needed in order to reach that goal.

The contract defines the following elements:

• Scope described loosely in a few paragraphs, a kind of vision statement
• An hourly price, that is 10-50% below what is normal for pure time-and-material
• A set of milestones, which will lead to payment of a fixed amount. The simple criteria that tells that a given milestone has been reached, is whether the software is deployed in production.
• A development process following agile practices
• A suggested time frame for the overall project and for each milestone

We are going to report on our experiences at Agile 2009, but don't hestitate to comment on this blog entry or contact Lars Thorup to learn more about agile contracting.
agile kontrakter

By Lars Thorup

Yesterday was a really long day, and I have to admit I was to tired to write a blog entry. So here is the field report from day 2 of our Lean study tour. To be completely honest with you - I felt incredibly privileged about what I experienced in Nagoya yesterday. First we visted Toyota Commemorative Museum of Industry and Technology and the Motomachi plant like Jesper mentioned in his earlier blog entry - I would definitely recommend both to anyone visiting Japan.

After the plant tour we met Mr. Satoshi Ishii who is a project general manager at the BR Automotive Software Engineering Dept. within Toyota. In short, these guys are doing all sorts of software that is embedded in modern Toyota/Lexus cars. Satoshi Ishii explained to us that a modern Lexus (Toyota's luxury brand) contains 70 or more ECUs (electronic control units) which all needs software (brakes, engine, fuel injection, navigation, adaptive cruise control, etc.) along with the ability to communicate with each other.

Before the meeting I was a little skeptical - Were the Toyota culture so strong that it had found its way into the relatively new field of software development? What might surprise some, was that they were using a waterfall model (in Ishii-san's own words - in reality I think it was more like the spiral model). In spite of that, I had a feeling afterwards that I had just talked to perhaps the most skilled software development managers I have ever met! Does that sound like a paradox? I do not think so.

Let me explain it this way. I once said to myself that I did not want to waste my time as a developer on non-agile projects. In the Toyota case, I would certainly make an exception. Why? Because I believe that the principles that this company is built upon is of far greater importance than any of the agile pratices that we spent so much time on in the Western world.

After meeting Mr. Ishii, I had a talk with Mary Poppendieck (who is also with us on this study tour) and she believed that this was actually the first time a Toyota manager in software development has ever spoken publicly about how they apply their (Lean) philosophy in this field - I almost had the goose bumps

Trust me... I will write more about the all the learnings of this meeting - but now it is time for preparing a presentation for the Agile Japan group tomorrow.

By Sune Gynthersen

Some interesting new tools in the field of continuous integration and code analytics are getting to speed and are exceeding past the old first-movers.
Two such tools are the build server Hudson and the “Code quality management platform” of Sonar. The first gives you a very quick to install and get running build server, with a very inviting and intuitive user interface and an open platform for third party plugins. Forget the dinosaurish CruiseControl (for Java at least) as the open source build server, Hudson serves you way better.
Your development team will love the excellent dashboard with sunshine and clouds showing how your projects are doing, and the metrics graphs with history of build and test results, build times, tasks etc. In terms of “smartness” it is said to read your Maven pom.xml and ensure that dependent builds are ran in the correct order (still need to try that).



Sonar joins a number of open source code analytics tools and puts it into a nice but at bit over cluttered dashboard. Look here to see a Sonar site of the Apache frameworks. I just want to show one of the features which I find most useful, the coverage cloud:



It identifies the classes probably needing an extra look, because complexity is running high and code coverage are running low. Brilliant way of visualizing code quality.

But remember: one thing is to know the state of your code –  another is to act wisely on it. Code coverage derived from automated test suites does not tell you, if you have assertions in your unit test. Without assertions you can add and delete code without test failing.
The violations of code quality rules and the complexity measures of you components, does not tell you if your design is thought out well, or express the domain your trying to support, only a combined effort of analysis with your customer and experiments can reveal this for you. But on the of path of getting less variation in code and fewer defects – that this getting closer to software nirvana – I will not be without Hudson and Sonar giving me daily updates on how we are doing.
By Jesper Thaning

As I'm beginning to feel a little stuck writing this blog-entry, I get a strong desire to check the news and see what happened in the world since I last checked 30 minutes ago. And I think I also need a fresh cup of coffee. I can imagine myself go down into the kitchen, boil water and add instant coffee to the mug, pour hot water over and add a little milk - heavenly! But instead of following my desires, I take a  look at the small ticking tomato-shaped timer in front of me, and I notice that I still have 15 minutes left to go. I put a mark on a piece of paper on my table, and turn my attention back to my blog-entry with a desire to keep going for the next fifteen minutes. I know very well that the desire to get a cup of coffee or check the news, are just a few of my procrastionation demons. They have haunted me for most of my life, but I now have found the ultimate weapon in the form of a small red tomato-shaped timer.

It was more accident than anything else, that led me to attend Staffan Nöteberg's talk about the pomodoro technique at this years agile conference in Toronto. This accident changed my life, and after that also the lives of my colleagues. Much would have been different had I known it 25 years ago.

The technique was invented by an, at that time, young italian student Francesco Cirillo, who was not too pleased with his own ability to study concentrated. As an experiment he borrowed his mothers kitchen timer, and tried to stay focused for 25 minutes. He did not succed immediately, but gradually developed the technicue to deal with internal and external interruptions. He developed a set of simple artefacts and  planning and improvement tools. As the technique matured, it was shaped to be used by others than just individuals. Also pair-workers and teams can have great benefit of the technique.

Curious? Check the links or attend my presentation in Copenhagen on Thursday  March 5th at 5pm - read more and register here.



By Bent Jensen

A task board has been used by many teams when doing Agile development to have a shared place to manage tasks in the iteration.  I have used it myself in a lot of different formats when working with R&D development, customer projects and also working together with offshore teams.

It can be a great tool for the team and creates more collaboration, feedback and risk mitigation when having a visible task board.

But, you might also have more frequent requests from other teams or customers and maybe you also work with maintenance tasks of existing products in production. It can be challenging to combine focus in the iteration with different ongoing requests.

One alternative approach to the traditional task board and iteration planning can be a Kanban system. Kanban is the Japanese word for visible card and originates from the Toyota Production System. It is used to minimize inventory, enforce Just-In-Time and eliminate waste.

I have used the Kanban approach to extend the traditional task board with limits on the number of concurrent tasks in different states to reduce work in progress and apply a more pull oriented process. When working with many different specialists in one team, I have also seen high value by extending the board with more states to manage the work of the different specialists. It makes it much more visible and easier to follow the flow and find wastes in the process.

In one team we combined the Kanban approach with a two week release rhythm and that enabled the team to both have a rhythm of planed activities and also do more frequent business requests depending on their capacity and the business prioritization.

The combination of the more traditional iterative processes together with a Kanban approach is very interesting, and I think many teams and organizations will find a lot of value and increased productivity looking into this area.

By Mads Troels Hansen

Maybe you have made some great improvements in your software development organization in 2008 and now it might be easier to reach the expected milestones and get value out to customers/users in a faster way. You might even have introduced some Agile or Lean practices (maybe Scrum) and started to work in a more iterative rhythm with increased collaboration and feedback.

Don’t relax and think it is good enough, because it can be so much better!

When your teams and individuals on a regular basis starts to search for new and improved ways of doing their daily work, you are moving in a direction, where more of the sleeping and hidden potential of the organization gets activated. When people get used to the rhythm of continuous improvements with regular retrospectives, instant kaizen events etc., they will start learning to see some of the candidates for removing wastes and be more efficient. 

Continuous improvements with a structured and constant improved process to find the most important candidates to improve, is key to more business success in your organization and it is essential for you to do it better than your competitors.

It is not only about improving development practices in your development team, because you might just sub-optimize areas with lower impact and poor ROI. Off course you can get a lot of value by having an efficient development infrastructure and teams working with automated testing, emergent design etc., but the bottlenecks might be in the value streams involving people outside development. Working on the right prioritizes with enough knowledge of the business problem, so you can make a simple and optimal solution, often requires an efficient collaboration between business the development team and here might be candidates for larger improvements.

Unfortunately I know of many teams and organizations not doing any kind of regular improvement activities in teams, projects or on a department level. That’s a shame, because they could do it much better and be much more competitive with an improved bottom-line in the company.

So start doing continuous improvements as an individual, in your team or organization, and you will over time learn to see what is really blocking you not to do it better. Just keep in mind that it can take some time and there are a lot of different techniques to get into the root cause of the problems, so you can focus on the constant and sustainable small steps with the largest impact.

By Mads Troels Hansen

I'm reading Dr. W. Edwards Deming's main work Out of the Crisis for the first time and thought I would share some of Dr. Demings wise words with you. I didn't really expect it but Dr. Deming actually has something to say about software development.

Earlier this year I had the pleasure of reading his other main work The New Economics and was amazed by the insights of Dr. Deming and how little people in general and management in particular have understood what he actually said. Granted, his overall style could easily be termed idiosyncratic and collage-like but stunningly concise formulations are spread all over.

This is what Dr. Deming said about the "supposition that it is only necessary to meet specifications" when it comes to software development:

"A programmer has a similar problem. She learns, after she finishes the job, that she programmed very well the specifications as delivered to her, but that they were deficient. If she had only known the purpose of the program, she could have done it right for the purpose, even though the specifications were deficient."

That's it! Did I mention that Dr. Deming wrote this in 1984, long before anyone talked about Agile software development?

By Thomas Blomseth

In a "Traditional"  approach to estimation a set of detailed requirements are analyzed, and from that analysis a solution is designed that will fullfill these requiments. We then estimate the time it will take for us to build that design.

If we do Agile development, we instead measure the relative size of each of a set of high-level requirements (e.g. in the form of User Stories). We then assign a conversion factor to the relative sizes of the User Stories, to be able to predict, when we can have what done. If we do not know how long time it takes, we can do a small iteration, and see how much we are able to complete in e.g. a week. We then use that knowledge to extrapolate from the whole set of requirements, to arrive at a delivery date.

If I am to choose from those two methods, I will greatly recommend the latter. simply because the detailed analysis and design, always misses something, and because it has an underlying assumption that nothing, or very little will be changed over the course of the project - thus the investment in the detailed analysis and design is justified. Anyone who has created software in the real world know that is never the case.

But both approaches treat estimation, as if the size of a piece of functionality or time it will take to complete it, is a real characteristic of the feature, and what we do in estimation is trying to find that hidden, true number.

I will call both these approaches Reactive estimation.


And off course there is something I will call  Proactive estimation. In this kind of estimation, the estimators acknowledge that creating a piece of software, is a creative process, where problems are solved on a daily basis, and that the level of teamwork, dedication, creativity and problem-solving skills are the factors that really determine the lenght of a software schedule. In this kind of thinking, a team will commit to deliver a product to a certain date, but they know, that what will be delivered, will depend on their ability to learn and solve problems along the way. The development process is then organized to accelerate learning, and plan  in a way that keeps decisions  open as long as possible. In that way the team will arrive at the best possible result at the given date.  Much the same way a play normally always will have premiere at the date that was planned months of even years earlier.

Does this sound to crazy to you? Maybe - but that is the way Toyota creates new cars, on time and with fewer resources than their competitors, and I am convinced that some kind of proactive estimation was used when the iPod and the iPhone was created.

By Bent Jensen

Back about a month ago we arranged a free lecture at the Copenhagen-based IT-University, with Lean Software pioneer Mary Poppendieck. Though a little late, we now have a copy of her slides available to all the participants. We very much hope you enjoyed the evening and got a chance to mingle with other agilists.

Download the slides here.





Some of the participants wrote blog entries about the experience. Check them out here: 100% Scrum is not 100% Agile and  Agile theses and mistakes


By Sune Gynthersen

Some thoughts that popped up on my first day of attending our Poppendieck course on 23th of June.

Knowledge inventory

The concept of “Zero Inventory” is not desirable and in fact does not hold in Toyota (go to the production plant and notice the trucks on the park yard outside the factory with inventory waiting to load it into the factory – the drivers are sleeping some times), its all about having the correct amount of inventory.
So! Mary keeps a log book containing what programs she installed on her laptop and what problems she experienced (hope she doesn't mind me telling this in public). When there is a problem on the laptop, she goes to look into the log book instead of googling it again spending time on finding the same site as 6 months ago, wasting time on finding already acquired knowledge – relearning, which is waste.  
Well. This log book is knowledge inventory. Knowledge that we keep close to us, ready to use, but it takes up space and the more we have, the more difficult it is to find the knowledge we need. In software we do not have physical inventory, like wheels ready put on a car in a car factory plant, but we have knowledge inventory. So how do we produce the correct amount of knowledge inventory?

Knowledge briefs

Lets go to the source. When we make knowledge and put it into our repository (perhaps a wiki), we should make the knowledge condense, then it is easier to find - and use. But it is difficult to make knowledge brief! If I make a four page documentation of a feature, and come back six months later, I will spend time  

Because knowledge in wikis are knowledge inventory, and tend to grow and grow. Too much get a burden, you cannot find things and when you find a document, its four pages long and the valuable knowledge is hidden in a lot of irrelevant noise. (Can search engines solve the problem of finding useful knowledge in a split second on the internet? I don't think so.)

So what about a wiki that have limited space? You can only put 2400 characters on a page, because if you put on more, you build up too much knowledge inventory. “If you cannot fit your knowledge into an A3, use an A4”. Constrain yourself to condense it even more – extract the important parts e.g. the exceptions in the business case that you only found out about later, and spent time on trying to grasp.  

I want to make an exercise on our next workshop to practice the art of making knowledge brief, to avoid building up knowledge inventory.
And last thoughts: Are knowledge always written? Can you build condensed knowledge in pictures and graphs?

By Jesper Thaning

Will Agile Software Development end on the dumping grounds of History? This June Mary Poppendieck will present her view on how the move to agile software development, needs to be done cautiously to avoid repeating the mistakes the IT industry has previously encountered while adopting new methodologies and paradigms.

June 23th and 24th, BestBrains is arranging a 2-day Lean Software Development course in Copenhagen with lean software pioneers Mary and Tom Poppendieck. In connection with this course we have also arranged a free lecture June 24th, at danish IT-Universitetet. Mary and Tom are well-acclaimed authors of the popular books "Lean Software Development" and "Implementing Lean Software Development", which describes how to use Lean principles to improve software development organizations.

See more about the comprehensive 2-day course here (or in danish here), and the free lecture at ITU here.

We are looking forward to seeing you there!

By Sune Gynthersen

Yesterday Jesper and I was doing an agile workshop as part of the Öresund Agile 2008 conference in Malmö, Sweden. I have to admit we had set out being pretty ambitious about the content of the workshop. We stuffed everything from Release planning, charting, coding, test-driving, continuously integrating, doing reviews, retrospectives, scrum meetings, planning poker, and discussing engineering practices and process improvement into just one day. I think we can conclude the workshop fully lived up to it's name -- Accelerated Agile!

With Malmö filled with swedish football fans, students celebrating final exams, and of course a lot of skilled people from the agile software community, we had some great days. Not only was it cool doing the workshop itself, but being at a smaller software conference where you actually get a chance to chat with most of the attendees I think is really valuable. I hope everyone else enjoyed it as much as we did (in time the feedback forms will tell!).

As promised during the workshop, we have of course put the latest (and hopefully greatest) version of all the slides online. You can download them from here.

After browsing through the pictures that was taken during the day, I selected some that you'll find below.

Notice the red and green lava lamps in the background. These were controlled by the CruiseControl CI server! I personally think that this was actually more than just a gadget. It brought great visiblity into the project. With these lamps connected to the build system, everyone who entered the conference room (or even looked through the door) could immediately spot if there was currently a problem. Now that is TRULY surfacing problems fast!

The self-organizing team working towards a common goal?

Some laid back discussions of interesting engineering practices.

Our one-day iteration ended with a retrospective, that judging from the smiles were rather positive.

All sorts of important stuff on the wall. Tasks, burn-down, WIP chart, and standard work sheets.

A big thanks to all the dedicated attendees, conference coordinator Gustav Bergman from Softhouse who invited us in the first place, and also Sonny, Lars and Thomas Lundström who assisted us during the entire day!

By Sune Gynthersen

During a presentation of the scrum principles this afternoon, participants were eager to discuss about what to put around a scrum process, feeling that something is missing in terms of well-designed architecture, thorough analysis of the domain and better knowledge about requirements.

Scrum is flexible and can fit into many different environments and uses, raging from product development, deliveries of customized software and maintenance inside an IT-department. It is also beginning to be spread into other areas than software industry!

So don't look for the silver bullet extension to scrum, but try to embrace the agile and lead principles when finding the right balance of planning your project.

One important lean rule:
If you need to decide on an important part of the system (e.g. your platform, database or ): Find out what is the latest responsible moment when the decision needs to be made. It is not easy, you will probably feel , but the longer you wait the more knowledge you will have the oppurtunity gain to support your decision, and you have the possibility to set start some experiments to search for alternatives. You might change your mind later regarding the latest moment, but that is the core part of agile practices: always be ready adapt to reality.

Don't be surprised if we write more on the lean and agile way of planning on this blog...

By Jesper Thaning

Last year in November I made a presentation on the Öredev conference in Malmö about my experiences with agile distributed development. In my years at SAS our team was at the remote end of a distributed development team, and I have since then helped a number of customers straighten out their distributed development efforts, with agile methods.

The presentation was captured on video and recentely the videos were made available. The video can see seen here

By Bent Jensen

Wednesday we visited NEC and Change Vision, both located in Tokyo. At those visits we got the chance to see one of the major Japanese corporations in the IT industry, as well a small software company.



We started out the day by visiting Change Vision, a company founded by Japanese author Kenji Hiranabe. We got a presentation of the two products of the company, JUDE and TRICHORD. Both seemed to be built on the idea of "mieruka" (making visible), which is a concept used by Japanese organizations for sharing information by making it visible in an easily understandable form.

While noticing the extensive use of simple visuals for tasks, metrics, ideas, releases and retrospectives, I have to admit what personally struck me the most was the bug-tracking system of Change Vision. It was visualized using LEGO bricks in a constrained physical space. This provides kanban-like control of the "bugs in process", by showing not only the variation in complexity of bugs, but also making it easy for everyone to see when you are running out of "slots" for new bugs, and thus have to start fixing some. Personally I just can't wait to try this visualization idea back home.

Judging by the discussions that took place after the visit, I think we all got a lot of inspiration from visiting a truly agile environment.

Later the same day we visited NEC for a techical presentation as well as a presentation focused on their development process. During the visit we learned that NEC had experimented with using Toyota Production System (TPS) a.k.a. Lean in the development process, for instance with the use of a kanban system to control the workload between different parts of the organisaion. Most surprisingly the system was put into place for controlling hand-offs between design, code, and test-phases. I think that as a group of agile thinkers, we were a bit stunned by this implementation.

NEC had also experimented with the TPS "stop-the-line" practice, in their development process, but had abandoned it due to inefficiency. Unfortunately we did not get a chance to hear the reasons that led to this conclusion.

(BestBrains getting a demonstration of Japanese innovation. This is an NEC electronic whiteboard with a built-in printer!)

By Sune Gynthersen

Last Thursday we had a workshop in BestBrains about Agile Planning and Estimation, with some lively and interesting discussions on the agile methods of estimating and planning.
One of the question that we only touched briefly was how to handle customer requirements that manifests as interdependent long running stories.

In the agile literature the examples where themes (an overall picture of a functionality) are divided into user stories (As a ... I can) are almost always simple and straight forward, but as many of us has experienced this is more the exception than the rule.

A scenario could look like this: Several requirements from the customer seems to involve the development of a common component (one example could be a layer of abstraction to a legacy system), with a complexity not suitable for a 2 week iteration.

One challenge is to give the customer a good indication on how much each requirement cost to produce, since the implementation of the first chosen requirement will suffer the cost of making the common component.
Another challenge is to deliver customer value at the end of each iteration with a complex technical task.

One alternative is to present the customer with the following choice between three user stories (As a ... I can), using the story point-method to indicate the stories relative size and not how long they will take to finish.

1. Tech Story - 24 story point (As a developer I can ... creating the common component)
2. User Story A - 4 story point
3. User Story B - 4 story point

Any one of A and B would require the tech story be implemented first. But when done the two user stories should be fairly easy to finish. One might think that the customer does not need to chose which user story goes first because the prelude is given.
The danger here is that the implementation of the tech story is not driven by a customer need and the team could make an over-complex implementation of the tech story, since both the user stories should be supported.

Another alternative is to include the technical complexity in both user stories:

1. User story A - 28 point
2. User story B - 28 point

This yields a somewhat false picture one might say, because we know that the relative size would never be 48 story point for the two stories because the second would benefit from the first, and we just have estimated the total work to be 32 points.

On the other hand this is the more true picture for the customer - at this moment in time - because the relative cost are equal for the two stories and the size of 28 story point could be compared to other user stories not listed here.
The customers task is to prioritize between the two stories and chose the one he favors most. The user story chosen will drive the planning of the first iterations, perhaps taken out as a series of spikes or experiments, trying to shoot a bullet through the whole stack of the system. The team should force themselves to consider how the user story can be split into smaller user stories fitting into iterations where the team commits to 7 story point at the beginning of each iteration.
One could imagine the CRUD operations (Create-Read-Update-Delete) split up into iterations taken one at a time or perhaps a light weight implementation with a small entity, saving complex data and business rules for later iterations.
After each iteration the team will know more about the user story and more about the complexity of the component, and they could soon feel the need to re-plan or re-estimate the stories with this new knowledge taken into account.

This shows the principle that above an accurate plan we try to help the customer to make a decision from the cost, and emphasize the teams focus on working on small customer-driven tasks. We value planning over plans.

In my opinion breaking down a 28 point user story into smaller tasks would yield a different result than breaking down a 24 point tech story that is made to support several user stories.

Even if the customer cannot decide which story that should be implemented first, the team should make a choice and pick one of them to start with (preferably the most simple one to make a quick proof of concept and learn fast, unless any risks could be minimized taken a more complex one) again to keep focus on a user scenario when diving into the technical problems.

This all shows that planning is challenging and never straight forward, and finding alternatives can give you valuable insight on how to plan your work. I do not know which of the scenarios you would choose or if you could think of a third or fourth alternative to meet the challenge of interdependent long running stories or another challenging example.

By Jesper Thaning

Just the other day I was thinking about the core ideas of Agile software development, and I believe I came to an interesting conclusion. I think the core of agile development is all about one thing -- Aggressively attacking risks. Well, maybe there is more to it  but that is what I'll talk about in this blog entry.

Whether you start up a new software project, or join an existing team that has been constructing something for years, you need to consider what the risks to the project are, and especially what you can do about them.

Risk of not shipping on time (or not shipping at all)
Practice makes perfect. Start shipping from day one -- That is, for instance ship a new release every week. Naturally it depends on the kind of product you are working on, but more than often this is perfectly feasable. In fact, this happens every single day for many web-applications, and users may not even notice.

Risk of building the wrong thing
Have developers work closely with users throughout the project, and encourage them to build an executable and testable model of the business domain, without too much focus on integration. This ensures that the product can in fact solve the core business problem.

Risk of not being able to integrate different parts.
If there is a risk of integration issues, practice! Integrate risky parts from day one of the project. For instance, communication protocols that you haven't tried before may be risky. While accessing a database may be a walk in the park. Find out which integration points require early integration, and balance those efforts against the efforts involved with the risk of "building the wrong thing".

Risk of high long-term maintenance costs.
What you need is a software solution to a business problem. What you don't need is unneccessary technical complexity. Aggressively attack complexity, and make sure your product is still capable of solving the business problem.

Risk of shipping software with defects
Where are your defects? In the business logic, or at the integration points between different modules? No matter which, the answer is simple: Test it (automatically) -- From day one! And use every single defect found, to improve the development process so that you introduce less errors in the future.

Risk of unacceptable performance issues
Have your team commit to a measurable performance goal. ...And you never guessed -- Measure it from day one.

The key to long-term success, is knowing what your long term success factors are, and figuring out how to address them on an everyday basis. What is our long-term succcess factor? I bet you are looking for a cost/earnings ratio close to zero viewing at the entire lifecycle of the software product. This is done by either increasing the earnings, or lowering the cost of development and maintenance. Also a short time-to-market is most likely attractive to your company. Thus, address those every day.

That's it for now. Keep working on reducing your risks out there.

 

By Sune Gynthersen

Three important principles of agile development are:

1. End to end development of small batches of work
2. Make problems visible
3. Limit work to capacity

Unfortunately it is not uncommon for teams, adopting agile methods like e.g. Scrum to somehow miss these principles.

I have a number of times watched teams plan and estimate work, they believe they can do in one sprint. After a few days, it is clear that the team lag behind. The immediate reaction is then to start to try to work faster, either by putting in longer hours or by sacrificing quality. In that way a Scrum sprints really live up it's name – a headless rush towards the goal. The result of having sacrificed all three principles mentioned above is a demotivated team and a growing pile of technical debt.

It is important to realize that the great benefits of agile development, will take some time to manifest themselves, and the best way to make them manifest themselves, is to avoid focusing too much on getting a lot dot done when starting to do agile development. Instead you should look carefully on how things are done.

For instance it is a common problem that developers lack information about features they need to work on, which will either slow them down or in order to not be slowed down, make them start guessing what it is they are supposed to do. This is a problem that should be made visible and dealt with at its root cause.

Another common problem is that features are not completely done when the iteration ends. Either they are not doing what they should, or is has not been verified that they actually work.

These two problems are just examples of problems a team starting to do agile development can and will encounter. It is important to embrace problems as opportunities for improving processes in a way that will create a more lean and flexible development environment.

So in your agile adoption:

admit we are all tortoises and we will not become hares just because we do agile development!

 

By Bent Jensen

Creating quality software on a continuous basis is a complicated business.

I think it is a sign of maturity if your team can admit that there are daily problems which are ultimately obstructing flow. While not everyone will appreciate that your team does a complete halt until the obstruction has been removed I think it is a necessity for a team to stay in good shape and continue to deliver frequently.

Just the other day I came to think about what were the most common obstructions of flow we see in software development environments. So here is my preliminary list -- I bet you have seen them all.

1. Build breaks
If you don't have a build, you don't have anything. Nobody is able to do any progress progress as the state of the product is unknown. Developers cannot check-in, as they will not get any response from the continuous integration environment. Testers cannot try out the latest build. Users cannot see the product in action, and the list goes on. A build break is like a blindfold, and you should treat it as such. Don't try to go anywhere until you have your vision back.

2. Test failures
If you have a failing test, you have dysfunctional software. Imaging somebody fitting some cool new styling parts on to a car with a busted engine. Now, who would ever do that? It really is the same with software. Why do any feature work on a software product which has a failing test? I know this can be hard to respect, especially when a deadline is closing in on the team. Deadlines however, does not justify continuing without stopping the line upon test failures.

3. Bug reports
If you have bug reports, you have dysfunctional software. There is no need to do any feature work, until the product is stabilized. Bug reports are even worse than failing automated tests as those bugs can only be reproduced by a human. You should not spend work hours on anything but writing tests for these bugs, and fixing them.

4. Any other blocks keeping the team from a steady flow
If you are experiencing an obstruction which is keeping from moving forward as fast as you could, suggest to the team that you stop doing anymore feature work, until you are able to eliminate the obstruction. One obstacle which I think is quite common is builds that take way to long time. "Yeah, but how can you build 2 million lines of code in less than two hours?" -- Well, I suppose you could start by reorganizing your code and build only the module related to a particular source control check-in. Hopefully you don't have modules consisting of 2 million lines of code!

I'd like to hear about any other obstructions you may have experienced in a software development environment.

By Sune Gynthersen

I think the most succesful software development teams are those who are fostering a culture of constantly trying new things out.

We have all burned our fingers on new immature technology, applying tools that were not the right tools for the job, or doing something we found out later was just plain stupid. While it may be just to blame whatever idea or product we tried out, putting the blame on the concept of "trying out" is taking a step down a dangerous path as it will lead to blaming those who are "trying".

I once had a talk with a guy that said something like: "We tried using frameworks and it didn't work, so we don't do that anymore" -- That may be trying, but perhaps a pretty early judgment on something as generic as the concept of a framework (It really sounded like the word "framework" was becoming taboo in that company). If you stop trying new things out I guess that means you don't care about improvements. 

Recently I had a talk about experiences with Stored Procedures. Perhaps you tried using Stored Procedures to solve a particular problem and it didn't work out very well. Now, that doesn't necessarily make Stored Procedures something evil that should never be touched again. Or how about build scripts -- How do you know if MSBuild or NAnt is best for you if you haven't tried both?

When we reach software nirvana I think everyone is accepting that trial and error really is the only way to improve, and thus encourage it as an everyday activity.

By Sune Gynthersen

There seems to be some confusion regarding what is lean and what is agile software development. Sometimes they are treated as essentially the same and at other times some (agile people) think that lean is just another management fad, while agile is the real stuff. In my definition Lean is a management system, that under a set of principles has as its ultimate purpose to eliminate waste in all processes. For each different business a lean system will look different. For a large number (maybe the majority) of software developing organizations, agile methods, are examples of processes with inherently little waste. So they form a good starting point for a lean organisation. Below that is a set of engineering principles (test early, continuous integration etc), of which many came together in eXtreme Programming, but has been used by good developers and organizations for many years. These are the sound groundwork any lean organization should build upon.
Computerweekly had this interesting article on the topic yesterday.

By Bent Jensen