The first of the agile testing days has passed. Weeks ago I classified the conference as minor and german. But when I learned at Agile 2009 in Chicago that many people are coming, I suspected that it is going to be bigger and more international than I first assumed. This has been confirmed today. Many interesting discussions and contacts spawned from the atmosphere that was created within the well equipped and arcitectural interesting venue.
A dinner downer: The speaker all took of for the speaker dinner, which left all of the regular visitors on themselves. Thomas and I will check were we can find other agile testers for dinner.
[nggallery id=13]
Designing a Lean Software Development Process, by Mary and Tom Poppendieck
Visited and written by: Andreas
According to the abstract of that tutorial, it should show possibilities how plateauing productivity improvements of agile teams can be analysed. Also options for improvements should be shown.
For analysing the existing process, it is feasible to visualize the value stream end to end: from the unhappy customer with a dedicated need for a new feature to the happy customer. The value stream includes all activities in between: for example marketing, product management, budget planning, recruiting, project staffing, design, development, test, system test, delivery, deployment or installation. After that you can look at how much calendar time is really used for producing value and how much waste you have in the process:
Process Cycle Efficiency = Value Added Time / Total Cycle Time
The problem with this metric is: the deeper you dig, the lower the number gets, because you will always find more things that are waste and not generating value. Still you can identify which parts of the process you should concentrate on for optimization.
The unhappy customer, the new requirements for the project, can be motivated by two factors: the “value demand” is demand based on a need for new features. Here you can surprise and satisfy the customer by exceeding the expectations. The “failure demand” is caused by mistakes you make. Here you can consider which actions could reduce the effort you have to put into satisfying the “failure demand” in order to get more throughput for the “value demand” (for example no 1st/2nd level support, customers talk to developers, they get direct customer feedback and can learn).
“Support calls are caused by a difference in mental models of developers and customers”
A strategy that does not work to increase the throughput is to just define new goals: Time to resolve a customer defect must not take longer than 20 days. You have to change the system, otherwise you will see no changes in the symptoms.
What happens with requirements that will not be processed in the near timeframe? You should accept that there is not only a “Now” and a “Next” release queue, but also a “never” queue for features. Customers do not really like to get a “no” for a feature request, but there are so more happier to get a reliable “yes, within the next 4 weeks”.
One of the most important questions during product and software development is: when will it be ready? The answer to this should not be, at least not according to the content of the tutorial, a schedule, but a reliable workflow. A schedule has the characteristic to utilize everybody for 100%, what will rarely happen in real life due to unforeseen events. Additionally a plan is trying to include all dependencies in a complex system, while a workflow can be controlled more easily. The “lessons learnt” from building the Empire State Building (about one year!) were:
- Design a system to meet the constraints; don’t derive the constraints from the design
- Decouple workflows; break dependencies
- Workflows can be controlled more easily are more predictable than schedules
For sure it is a question of lacking practice, but right now I can hardly imagine how to design decoupled workflows in software development – this is why in Scrum all thing neccessary to get a feature done are within one Sprint, in a sequence that is most appropriate for the Story at hand. Speaking of Scrum, an interesting quote: Scrum was designed to adress the scarce resource of software developers.
In retrospect I think that the stories and examples in the tutorial (Construction of the Empire State Building and Southwest Airlines not focussing on load factor) were entertaining and inspiring, but I think I would have liked examples from the world of software development better, just to see that the principles all apply also to software development.
Acceptance Test Driven Development (ATDD) in Practice, by Elisabeth Hendrickson
Visited and written by:Thomas
Ok, what do I take home from the tutorial “Acceptance Test Driven Development (ATDD) in Practice” by Elisabeth Hendrickson? First of all roughly 10 Din A4 pages of notes which clearly indicates that this was really a very interesting event. But beside a lot of paper there have been also a lot of concrete ideas how to take ATDD into use more in our own projects. On the other hand it is also very interesting to hear the different experiences on this topic from other participants of the tutorial. By this it was becoming quite clear that currently for most people there a still a lot of problems. Here it is not that much a problem of technical issues or the tooling, but a lot more on the organisational side. With this it is very much the same as with introducing other agile practices to organisations.
The tools and processes behind ATDD very well fit to organisations that have already been successfully adopted agile practices and here it really offers the chance to create additional value. This is supoorted by the fact that also the tools are making big progress all the time and of course I was very excited to see some new feature of the Robot Framework in action that allows to define requirements in sentences written purely in English language (of course there is some magic behind). With this tests can be implemtend as “Executable Specifications” and thus form a common foundation for the product owner (= customer) and the development team.
In the following a short list of Quotes collected during the tutorial.
- The Technical Team is “The tribe of the how” while the Product Owner is “The Voice of the What”. See also Agile Anarchy
- A bug is a valid expectation of the Product Owner that is violated.
- How do we test automated tests? Explorative Testing
- Lean does not mean: Be stupid!
- Gold plating is a big risk in Software Development, as it creates things no one actually wanted.
- Agile is the most diciplined software developing approach.
It was also getting clear – once again – that a successful development team (e.g. a Scrum team) must have all required skills within the team. It is really bad to have any kind of silos, e.g. by putting testers or architects to own teams. This goes to the same direction that Boris Gloger was pointing out at our last Meet the Experts where he was saying that every member of a team should be able to perform 90% of the tasks that team has to perform. During the whole time it really became clear how difficult it is to start with ATDD unless you have some agile foundation to build on. Elisabeth was also emphasizing that you need both: Test automation and an agile approach. Those things do not work without each other. Probably this is a good closing word for the summary of the tutorial.
Was this post helpful?
More articles
fromAndreas Ebbert-Karroum
10.2.2015 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Blog author
Andreas Ebbert-Karroum
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.