When the customer is not at the site, the Product Owner of the team is but a proxy that tries to translate the customers needs to detailed functionality. To make sure the customer is happy, the Product Owner needs to discuss solutions, and needs to get questions answered quickly on behalf of the developing team. We have collected and tried out various ways to bridge the gap between the team and the remote customer, who is the real Product Owner. This talk gives some examples on what went well, and what can be done better.
This lightning talk will share my experiences from an effort to create a more agile code base from legacy code with no test coverage in two weeks. I’ll share what worked, what didn’t work, and the importance of being pragmatic rather than dogmatic.
Practicing what we preach. We shall conduct a daily retrospective of the conference, before we end a day. Assemble the willing participants to share their feedback: what is working well, what needs improvement, etc.
This will provide valuable feedback to conference organizers as well as speakers to make the rest of the conference even more valuable for participants.
As agile has gone main stream, we see self proclaimed agile projects roll out large scale, overly complex CMS’s and CRM solutions - the notion that going agile would affect the technological choices is foreign.
The change needed is a revival of XP’s values of Simplicity and Courage. Simplicity to make sure that we build solutions that are cost effective and maintainable, Courage to take a stand and point out that to reach its full potential agile values must affect technological decisions as well.
Here are some metaphors that I find useful when describing software product development. In particular, they are useful for describing the basic principles of agile development and the lifecycle of a typical agile project. Learn why software development is like releasing a music album, producing a magazine, staging a theatre production, or producing a film. I will present some justification for each metaphor, and describe how and why I find it useful. I will describe their usefulness as metaphors for software development in general, and for agile development in particular.
We are terribly concerned about being done with things. But are we really ever done with things? Done is an ambiguous term. Why else would we need a Definition of done? Definitions of done normally includes quite a few activities, but why are they concealed in a definition? Sometimes “Done” is at the same time so desirable and ambiguous that teams have two or even three versions of it - “Done Done” and “Done Done Done”.
Teams should discard the notion and need of being “done” and instead find the real states that their tasks have and make them visible.
We have several techniques to become more agile when writing code. We apply design patterns and use practices like pair programming and test driven development. But how can we get more agile in the way we design the user experience of our applications?
In this lightning talk I will give an introduction to UI prototyping and how it can help your team become more agile in the way you work with user interface design.
(This session was given in Norwegian during the Smidig2009 conference in Oslo: http://smidig2009.no/talks/111)
Adopting Agile as a set of “codified” practices mostly from the arena of Scrum an XP gets you so far, but what practices are for senior managers to do ?. What do they need to promote and how ? In this talk I will discuss some practices that we are using with senior managers to promote the agile culture including openness, learning , collaboration, reward systems, and technical excellence.
Even though many projects are doing what the call agile; standups, backlogs and some automated testing, they are not reaping the full benefits. Proving you can adapt to circumstances by shipping new versions rapidly will be the true test. And it doesn’t matter if you’re doing agile or not: Getting to that point will expose problems in your process andhelp you achieve your goal of delivering quality software that solves real problems for real customers.
Prove that you’re doing it right and ship it!
From infancy, we use metaphors to make sense of abstract concepts. The metaphors we choose have huge cultural significance, and bring with them both a rich vocabulary for discussing the target concept, and a bag of related concepts. And if we are not careful, we can sometimes believe those related concepts to be true of the real situation, forgetting we are in the land of the metaphor.
So it is with some architectural patterns — notably those that make use of layers. This session will shine a light on some assumptions we make about software when we forget we are in the land of metaphors.