Archive for the ‘Consulting’ Category
Posted by James King on February 10, 2012
Life used to be easy for managers. We had good people who delivered lots of stuff and bad people who stuffed up lots of deliverables. It was easy to tell who the good guys and the bad guys were.
But then something significant happened. We discovered that work was not just about performing a set of predictable tasks. We started to realise that:
- Work was about adding value rather than destroying value rather than just delivering stuff; and
- We started to see value as something delivered through the interaction of entire teams and not through individual achievement.
Read the rest of this entry »
Posted in Capability growth, Leading change | Tagged: leadership, matrix structure, performance agreement, tester | Leave a Comment »
Posted by James King on February 9, 2012
Everywhere I go I am starting to notice consistent problems or patterns of behaviour that hold back some of the best people in the teams I work with. I think they are starting to rank right up their with the Peter Principle as ways to stop good people from reaching their true potential and really contributing value to the teams they work with.
And they are all related to the managers in the team not having enough time to talk about succession planning.
Read the rest of this entry »
Posted in Agile development, Capability growth, Leading change | Tagged: succession planning. people leadership | 2 Comments »
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 | Leave a Comment »
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 | Leave a 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 | 2 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 | 2 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 Implementation, Measurement, Agile development | Tagged: agile testing, regression testing, testing robots | 1 Comment »
