Posted by James King on February 9, 2012
Stepwise programming is a very useful way to prioritise when there are many variables at play.
The key benefit of the approach is that you do NOT try to understand and prioritise every thing at once against everything else. Instead you break the problem down into very small pieces and move through each one methodically. You then come up with a ranking of the importance of each variable from top to bottom.
And the approach scales well. You can do it on your own or you can get a lot of people to use the process at once to form a consensus about what issues really matter the most. I have used the approach for everything from setting priorities in retrospectives to ranking the capabilities needed in a team to structure more effective training.
Posted in Observations | Tagged: prioritisation, problem solving | Leave a Comment »
Posted by James King on February 8, 2012
Regression testing is the easy part of IT development, not the horrible monster some people think it has to be.
But where do you start if you want to do effective regression testing, but you are already busy and don’t want it to be huge burden?
I hope this article and a couple that follow will turn out to be a guide to one painless way to get regression testing up and running. Let me know if it helps.
Read the rest of this entry »
Posted in Agile development, Implementation | Tagged: agile testing, regression testing, UAT | 2 Comments »
Posted by James King on February 8, 2012
Before I worked in IT and even knew what testing was, I knew people made mistakes. But I didn’t know there was an international standard you should comply with when you want to make a mistake.
Then I worked on a project with a mining company and one of the consultants explained human factor analysis to me in simple terms. He told me that mine sites can be dangerous and part of his job was to “stop people killing themselves when they are stupid”.
I suggested he stop hiring stupid people but he told me that they tried that and it didn’t work. Apparently you can be really intelligent on a mine site 800 days in a row but then be stupid for 10 minutes one day and be in an accident and then be killed.
“Luckily we have a standard for being stupid though” he said
Read the rest of this entry »
Posted in Agile development, Idea management, Implementation | Tagged: agile, human factor analysis, regression testing, testing, UAT | 1 Comment »
Posted by James King on February 6, 2012
I have been creating a couple of blogs on context recently. The idea is that if you know a bit about your users and the product that you are building. Both can take months or years, but I like to think we can even spend an hour or less to understand our project.
Read the rest of this entry »
Posted in Agile development, Idea management, Implementation, Leading change | Tagged: agile, managing ideas, project charter, project launch | 5 Comments »
Posted by James King on February 6, 2012
I was speaking to a crew who were struggling with regression testing and after interrogating them they finally admitted that a large part of the reason they were struggling was that they did not really understand what they were testing.
I was shocked and horrified so I wandered off.
Soon after I spoke to some business analysts who were struggling with an agile project. They alleged that the agile approach they were using did not allow enough time to capture the requirements properly. But guess what, they broke down under interrogation and admitted that a large part of the problem they were having was that they did not really understand the product they were building. Apparently the evil agile people had forced them to write stories about the system before they had time to understand it.
Read the rest of this entry »
Posted in Agile development, Idea management, Implementation | Tagged: agile stories, regression testing, requirements | 3 Comments »
Posted by James King on February 3, 2012
If you want to do a Phd in human psychology, then grab an IT team and ask them to do regression testing.
Regression testing is simply the idea that when you make changes to a system you should test to make sure you haven’t broken what was already there. But for reasons unknown to psychologists, IT teams fall into a strange psychological pattern whenever asked to do regression testing. This is the opportunity for someone to do a Phd – we understand that people consistently adopt the same four stage cycle of pain, but social scientists are at a loss to explain why:
Read the rest of this entry »
Posted in Agile development, Implementation | Tagged: regression testing; production suppport; agile testing, scenario testing | 3 Comments »
Posted by James King on January 30, 2012
I wrote an article on stories for production support teams quite a while ago. But I always meant to add a couple more.
The problem with production support is that nobody has time to ask for what they want, but it is all urgent and super critical. So the last thing you often feel like doing is to slow down and understand the context that the user is in (annoyed, relaxed, sitting in a cafe, in their most important sales meeting ever etc). Instead the focus is usually on fixing “it” before you know what “it” really is.
But this often leads to rework. So whenever I am doing enhancements I always spend a little time understanding why the enhancement is needed, who it is needed by and when/how it is likely to be used in the real world. To do this though, I think we always need to spend a little time understanding the people who will use the system and why they need something new.
There are many approaches to doing this, but one I often find useful is “PAC” or “People, Activities and Context”.
Read the rest of this entry »
Posted in Agile development, Implementation, Investigation | Tagged: production support, testing, usabilty | 3 Comments »
Posted by James King on January 30, 2012
I have often found that regression testing is both important and boring, so I usually try to automate it as much as possible.
Unfortunatley there there is often little or no automation in place at all when you join a new team and there is often not enough time to get it working properly before the next release.
In fact though, even when there is a lot of automated testing in place, I have sometimes been surprised how quickly a good business person will find a significant bug by simply sitting down and mucking around (playing) with a system for an hour.
Read the rest of this entry »
Posted in Agile development, Implementation | 1 Comment »
Posted by James King on January 27, 2012
I often work with good developers and one thing I notice about all good developers is that they seem to love the idea of building robots.
Bad developers see problems and sit there waiting for someone to come up with a solution in enough detail for the developer to transcribe the solution into code, much like an old fashioned typist takes dictation and types it onto a page.
So if a bad developer noticed that their house needed cleaning, then he or she would simply complain that someone should clean it. Then if you point out that it is their house that needs cleaning then they will either claim management won’t let them clean or that the problem is more complex than it seems cannot be solved.
In fact even if you ask them to try and clean, they will just start to reveal that cleaning is “more than vacuuming” and could involve the removal of micro-particles that only quantum physicists could possible manipulate. Indeed, they will contend, it is unlikely that anyone really cleans their house and the only practical solution would be to upgrade to a new cleaner house.
But good developers are different. A good developer will notice that the house needs cleaning, work out that actually cleaning it less fun than designing a better way to clean houses and immediately begin working on the design for a new robot.
Read the rest of this entry »
Posted in Agile development, Implementation, Measurement | Tagged: agile testing, regression testing, testing robots | 1 Comment »
Posted by James King on November 4, 2011
I sometimes quote ISO90210 (not a real standard) to represent a common approach that, while often used, is not a formally recognised standard. It is more a common but informal way people approach something.
In this case I am looking at how to be scared.
Apparently there is a standard approach to being scared that inolves the amygdalae in our brain and us cheking our big catalogue of things to be scared of when any event happens. But that is a biological response and I am more interested here in a project management response.
So here is where I start – the ISO90210 standard for being scared at the start of a project (or halfway through):
- For both Product risk and project risk (see below for the definitions), write down a list of:
- What could go wrong?
- What would cause it?
- When and how would we find out?
- What would happen after we found out?
- Once you have a long list, review the list and look for patterns:
- Are any 2 things symptoms of the same underlying cause or event?
- Do several bad things result in a similar bad outcome?
- What is the level of risk outrage – ie how pissed off would the stakeholders be with each, regardless of how bad or mild it really is?
- Ask yourself – If one or two of these did happen, which ones would they be?
- Ask yourself – If there is one thing we know we should deal with, but probably won’t, what would it be?
- Consolidate your list into the top three (or 1 or 5):
- Which 3 things should we be the most worried about?
- Why them in particular?
Then you have a consolidated list of what you should be the most scared of. The final steps are:
- Compare your list to what others came up with; and
- Discuss what we should do about the combined list of concerns.
Note – it is worth looking at both product risk and process risk:
- Product risk is the risk that we will deliver the project but that the product we deliver will not do what we want (it will fail to meet expectations or do unwanted things). For example it might not sell or it might canabalise demand for another product; and
- Process risk (or project risk) is the risk the project won’t deliver the product we have asked for when we want it. Examples include too many bugs, a restructure impacting the team and so forth.
At least if you are going to be scared (which you should be on every project), you can now do it properly.
Posted in Risk | Tagged: pragmatic project management, risk, team based risk management | 3 Comments »
