Agile assists, Scrum saves, testing turns profit – or do they?
AKVA club of HETKY organized a seminar about agile, scrum and testing. It was a two-day cruise from Helsinki to Stockholm and back and there were many speakers from different backgrounds. There was a common (though unplanned) theme – doing agile is not easy.
Pia Ek: How one should regard agility contract-wise?
First talk was from Pia Ek of Hannes Snellman. Her main theme was that agility doesn’t contract-wise differ that much from traditional methods of contracting software.
First, one should always have a contract – and preferably in written form.
Second, the contract should always be exactly about the thing that the parties are agreeing on. It’s not useful – especially on agile contracts – to start from a specific form of contract. It’s irrelevant to talk whether it should be “fixed price” or “time and material” -based. Contract should be based on the mutual goal – what are the responsibilities of each party and what is the acceptance criteria.
Third, agile projects are usually considered as a series of mini-projects. Each iteration should have a clear planning phase during which it’s clearly stated what is going to happen during the next iteration. It makes it possible to make a contract for each iteration – if that kind of extremity is needed.
Fourth, if product development is done in agile manner with close collaboration with customers, it may come to question, to whom the IPR belongs. This should be mentioned in the contract.
Finally, although agility is based on changing requirements, changes must still be handled consciously. They must not cause unhandled chaos.
Often projects go astray due to customer not playing it’s role well – either by not handling it’s responsibilities or not reserving enough resources to the project. This theme were continued on the next talk:
Esko Hannula: How do you make sure that your IT-purchase succeeds?
Esko believes that agile methods are the best thing that has happened to software development for a long time. At the same, he is really concerned about the way that agile is applied right now. He predicts that in next few years many companies will suffer from serious “agility hangover”.
Agile will eventually – and when performed well – make huge profits but before that it will make many suffer.
Esko told that customer will always suffer more from quality problems or projects that otherwise didn’t end happily. By using strict contracts it’s possible to even run the supplier to bankruptcy, but the customer will still suffer more – if it won’t the project were not worth starting after all.
To avoid quality problems and ill projects all teams should remember a few things:
- Agree on who is responsible on quality assurance and acceptance testing
- Re-think the chapter “change management” on old contract templates
- Bring all problems visible and handle them actively
- Changes in projects should not come faster than decisions can be made
My own talk: Scrum pitfalls, and what does Scrum demand?
I proposed that Scrum is difficult but required. Period. At least on product development. On contracted customer projects, it’s valuable but can be discussed on. My main points were that Scrum is difficult to both individuals and organizations.
Traditional project managers get lost when they don’t have their familiar tools to manage projects:
- there are not necessarily functional specification, architecture documentation and other typical planning documentation
- Progress reporting is done through daily scrums and burndown charts
Traditional project managers get lost as their usual activities exist no more:
- They don’t do task splitting
- They don’t tell people to do things
Traditional developers get lost, when they need to take more responsibility:
- They don’t get ready specifications from which to code. They may need to write them themselves.
- They don’t necessarily always know what they are going to do next, nobody will tell them. They need to take the responsibility of getting things done.
Traditional developers try to avoid the responsibility when things go wrong:
- They say that they only did what somebody ordered
- They say that they only did what is said in specification.
For Scrum to work, it asks many things from organizations:
- It should be learning organization, always getting better and better. It needs that people get and give feedback regularly and that teams hold retrospectives.
- One must have an atmosphere of trust. Learning takes many mistakes and learning from mistakes needs good team spirit. And it is not possible without trust.
- A decent product owner. A scrum team needs a prodcut owner that is capable of doing priorizations.
- A decent scrum master. Team needs a dedicated scrum master that is empowered to make needed decisions to remove impediments
- Scrum teams do not have HTML-specialists, programmer, DB admins, tester and technical writer. Scrum team is a cross-functional team where everybody is required to do whatever activity is needed any given time.
- Scrum team cannot work by themselves. They need a good Scrum-aware surroundings, especially in marketing and sales but also in upper-level management.
Some typical pitfalls that many organizations fall into include the following:
- Pretending that Scrum is easy
- Leaving the Scrum team alone, without support from higher level
- Using agility as an excuse to cowboy coding)
- Forcing the use of Scrum from upper management, without buy-in from team
- Forgetting the retrospectives, retrospectives that really form the basis of Scrum.
- Closing eyes, and staying using Scrum by-the-book even though it doesn’t work
Some random points
Riitta Karkkila from IBM Rational spoke about their transition towards agile methods. Even Rational must have admitted that today’s world needs different type of software develoment compared to 80′s and 90′s. She told that in software development, you need four types of management:
- Scope management
- Process management
- Progress management
- Quality management
These together make sure that development sits happily on its pillars, collaboration, automated testing and process improvement, and measurement. On top of these fundamental principles are a few practises how you make the product good enough in given time with given resources:
First you timebox, then you go breadth first and prioritize, then go into more depth and details and finally iterate the whole process until you are finished.
Hello from Russia!
Can I quote a post in your blog with the link to you?
Yes.