Archive for the ‘Implementation’ Category
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 September 30, 2011
I am currently trapped in the real world … working on a real project rather than running a training course on how to run projects.
Interestingly it turns out the real world is harder and more ambiguous than the projects in my training slides 
Having said that though, the fundamentals don’t seem to change. We have stopped a project and are about to restart. It is really urgent and we have inherited a project whose budget (in time and money) has already been spent. So we really need to get going.
But are we better off starting or are we better off getting our act together before we start so we are not “mistaking activity for progress” by rushing off in the wrong direction?
Read the rest of this entry »
Posted in Implementation, Observations | Tagged: and retrospective, backlog, eek, iteration, planning under pressure, wrong direction | Leave a Comment »
Posted by James King on April 22, 2011
The world’s simplest communication plan might be this one:
- Who I am communicating with?
- What should I be telling them?
- How should I communicate with them?
Even thinking about those three questions on the bus on your way to work might help create better communication. But I thought I would break the questions down to come up with a slightly more complex plan that is still not hard to do.
Read the rest of this entry »
Posted in Implementation, Leading change | Tagged: commucation plan | Leave a Comment »
Posted by James King on March 16, 2011
I was running a course in agile development when I mentioned that one of the good things about agile is being able go live with something valuable sooner.
One of the class asked whether you can measure the benefit of going live sooner. “Of course,” I replied, “and of course you should be doing so”.
Some of the group asked if we measured value in features deployed or some other way. So we had a good discussion around measuring value.
But then one of the group told us that his project was about “simplifying IT” and so his agile project manager had told her that, since the project was not adding any value to “the business” the only real measure of success was whether they deployed the features they were supposed to deploy.
But this seemed a bit silly. So we agreed that adding value to IT was in fact adding value to the business, since IT is part of the business.
Read the rest of this entry »
Posted in Agile development, Implementation, Measurement | Tagged: measuring maintenance, production support handover | Leave a Comment »
Posted by James King on February 10, 2011
What knowledge does a production support team need when a project goes live? And what do project teams actually give them?
Some agile teams catapult story cards across to the support team with no thought as to whether these will be of any use to anyone.
Even worse, some teams think that being “agile” means “never having to document anything and never having to say you are sorry”.
Read the rest of this entry »
Posted in Idea management, Implementation | Tagged: agile, knowledge management, production support handover | 1 Comment »
Posted by James King on February 9, 2011
This article is one of a couple I am writing to explain how agile projects can hand over useful information to support teams if they want to.
So this article is a (hopefully) straightforward description of how we can use stories to define the knowledge that to create and handover when the project goes live.
Read the rest of this entry »
Posted in Agile development, Idea management, Implementation | Tagged: agile documentation, agile knowledge management, production support handover | Leave a Comment »
Posted by James King on February 2, 2011
To really understand any team, it is important to understand the distribution of power within the group and how that power is exercised.
Read the rest of this entry »
Posted in Implementation, Investigation, Leading change | Tagged: change management, politics, power, teams, tribes | Leave a Comment »
