Every retrospective I do on every project seems to include the conclusion that “we need less meetings, less emails and more communication”.
In fact SCRUM and agile approaches even try to define the bare minimum number of meetings that are needed and only have them (Actually one of my friends claims that they have removed all the meetings – “In agile we don’t have meetings, we only have workshops. Meetings are discussions and Workshops produce something tangible each time”).
Yet the reality seems to remain that meetings (or workshops, or gatherings, or war councils) often end up getting in the way of doing the real work:
So what would you do if you had to look at the return on investment of each meeting? Would they actually stack up from the point of view of making money for shareholders, making life easier for the crew or improving the experience for our customers?
Continue reading “What if people thought meetings were actually work?”
I don’t normally publish links on this blog since I prefer to add my own views or approaches. But there is not much I can add to this one. People sometimes ask me for links to some of the material they see, either in course material or when I go wild and draw random things on the whiteboard/wall. So here is a link to a new initiative set up by the agile alliance. It appears they are finding and listing the wide range of techniques that people describe as “agile”. It will no doubt be a good place to go … Continue reading A general guide to agile practices (actually a link to one)
This article is part of a series on making regression testing useful rather than painful. The most recent article was (as you would guess from the title to this one) about day 2 of our regression testing adventure.
So far we have been looking at how to do some testing, and then do some basic scripting and mapping as we do more testing. In doing so we have (hopefully) been learning more about the system we are building but our main focus is on making sure it is still performing the way we want to.
Now we are going to evolve our testing onto a proper OODA loop. I have created another article to explain what an OODA loop is, but for our purposes it means this:
How fast and how well can the team move between the following 4 tasks?
- Observe the world around them – the way users are operating, the way the system is performing and the way things are coming together.
- Orient themselves or make sense of all that data (interpreting, analysing, integrating and assessing).
- Decide what to do next with all that information.
- Act on their decisions as a cohesive group.
To do this we need a little lesson in OODA regression testing theory
I was watching Star Trek a couple of weeks ago and I was thinking – wouldn’t it be cool if work was just like Star Trek.
Then I realised that work is actually a lot more like Star Trek than I thought it was, so let me explain:
The whole crew nearly die in every episode in Star Trek (we don’t nearly die each week, which is good). Since they are in a starship, the Star Trek crew’s survival almost always depends on their ability to work with technology. But I guess the show would be a little boring if everything worked as planned:
Captain: Yikes – that looks like a rare Lithiam based ameoba that eats starships, we need to warp out immediately
Pilot: No problem, the engines are working well within their design perimeters. We have escaped easily.
(end of episode)
We don’t see many episodes like this though, we see the ones where they are in real trouble.
Continue reading “It is technically impossible, but is it really?”