Agile is great for projects with challenging deadlines and changing requirements. During yesterday’s training we had a discussion on how to balance between tight cost constraints and changing requirements. How can you deliver your project within (to an upfront agreed) budget knowing the requirements will change?

One option we discussed was the following:

• Use planning poker (or other estimating tools) to estimate the known requirements and fix a budget for a bucket of points (let’s say 100 € for 100 points). Whenever new requirements pop-up you can trade them for what is left in the bucket (let’s say you have delivered already 30 points, then the product owner can trade the other 70 points for new/changed requirements. These requirements should be estimated using the same technique of course).

I used this technique once in a fixed price project some years ago. It helped the customer to introduce change (hence better value) and me to keep my budget (and margin). However this was based on mutual trust and the willingness to defend these “trades” within the customer and supplier organisation.

Anyone has other ideas/experiences on keeping the balance between changing requirements and tight budget constraints?

Scrum (and Agile) is becoming the mainstream software development method. Not all of us are doing it the same way (as in fact everybody did some sort of Waterfall back in the previous century).

One of the reasons for this success is the sheer amount of information on the net on Scrum and Agile methods. It accelerated the adoption of Scrum and more and more people turn to the net when looking for answers on Scrum and Agile challenges they face.

That’s why we offer an online 2h Scrum starter training. It’s only 2h because the basics on Scrum and Agile are widely available. However during this starter training we will share our experience in adopting agile and help you setting up your specific Scrum projects. Have a look at the AgileTeam Scrum training for more information.

The Alistair Cockburn keynote is very entertaining and he shares his ideas on the future of software development processes.

In a first part of this session AgileTeam will give an overview of agile software processes and practices. Main focus will be the setup, pitfalls and key success factors of agile projects, based on our experiences at several customers from different domains and numerous projects of different flavours.

In a second part of this session two testimonials from practice will be given on ‘distributed scrum, agile software practices for development teams across multiple locations and continents’ by Chris Van Loock from Scia Group nv and ‘introduction of agile principles in an existing framework, an iterative approach’ by Thomas Moens from Materialise nv.

We are very happy to be given this opportunity and look forward to discuss your ideas with us at this event.

Sell your product

About a week ago AgileTeam held a session on software innovation - the fast lane to happy customers @ KVIV.

Participants were asked to create a product box for their favourite gps device based on material they could select from some glossy magazines. Later on they were asked to sell their product to us, representatives of a major gps manufacturer company. Some interesting observations were made:

However at some point in time new development is needed. So we need a practice that allows for new code but stays close to the idea of avoiding to write too much code. That’s why I favor the piecemeal growth practice.

Piecemeal growth advocates to deliver smaller chunks of software code to your users and generating feedback frequently and rapidly leading to:

• better quality (less code means less bugs and smaller efforts to stabilize). It is easier to keep a bugfree system bugfree then to debug a large system with poor quality.
• to the point software (too often a project tries to deliver too many requirements at once, once confronted with the software our users want something else leading to even more software requirements). By showing small chunks of software, users can see what they need and step by step growing the software in the right direction

This session is titled ‘Software innovation, the fast lane to happy customers’.

Due to its important role in products and services, software is central in the innovation strategy of many companies in order to target new markets or applications.

Moreover, time-to-market is increasingly important in today’s market. Therefore there’s not a lot of room to perform a quest for the perfect product.

In this session AgileTeam highlights a number of ways of software innovation. Special attention will go to the ‘small innovations’ that allow you to gain the maximum out of your existing software.

Aspects that are touched are:

• how to discover what makes your customers happy?
• how to check the feasibility of your idea with a minimum effort?
• how to develop your idea into something that the customer will buy?

Attendees will go home with a number of practical techniques that allow them to involve their customers in their innovations and to reconcile marketing’s wishes with engineering’s capabilities.

We are very pleased with this opportunity and hope to meet you there for a chat in real life! Check out http://www.ti.kviv.be/softwareinnovation for practical arrangements.

Product box for software analysis methodology

One of our customers is in the process of choosing a package solution to replace in house developed applications concerning project management (dashboard, time-sheeting,…).

Last week I was asked to make a high level description of the portfolio management tool they build in Excel (it is not documented as will 99% of all Excel apps).

I immediately was thinking “Innovation Games”. For those not familiar with this check out the website. These are great tools for getting customer feedback on your software products.

I’ve been using product box, remember the future and speedboat several times in the past to better understand what customers want. For example this picture is a product box for a software analysis methodology, certainly the “strangest” application I’ve done so far. However it worked well, the software analysts could express what they really wanted from their methodology (I personally like the picture of the women sleeping, it represented the wish from the chief architect that he could spent quite nights, not worrying some developers were writing the wrong code.)

However could I use these wonderful tools for creating a high level description? We need this description to explain the package tool vendors what the customer wants. No better way then to show them how our tools are used today

I chose  “Show & Tell”. I asked the key user to show me how he uses the Excel application in his daily work. He brought some screen shots, emails and reports and he explained during 20 min his work. Really show and tell!

I made a mind-map of it containing my notes and his screen shots. So after less then two hours I had a high level description and got to know the Excel application better. We start the selection process middle of March and can’t wait to get feedback from the vendors!

He was wondering how to merge these two worlds, agile software development and the zero defect philosophy of Crosby. At first I was a bit confused because for me agile development means zero bugs (and yes a lot of people declared me insane). This idea of course pleased the quality manager.

However he was worried about the self organizing teams. How could he prevent the software developers to start coding without a formal analysis review?

So I explained the idea of potentially shippable product and the sprint review. A product should adhere to the highest quality constraints imposed by the company. At the sprint review you could check if these are met . So if these standards would be explained during the sprint planning by the product owner, the team could plan these activities as part of the delivery.

However this would again mean that you have to trust your teams in delivering without interfering in the details of a sprint. Past experiences have proven that teams are able to plan iterations for themselves leading to increased productivity. So let’s do the same for quality, the product owner should define the quality standards and the team will be able to deliver the software that adheres to these.

So invite your quality manager into the product owner team, he or she is invaluable in defining the quality standards and accepting the software product during the sprint review. That is what we are going to do!

This blog is there for anyone interested in the evolution of our company and keen to share our ideas on agile software development and software architecture.

See also our webiste www.agileteam.be