Archive for the ‘Techniques’ Category
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 »
Posted by James King on October 27, 2011
I run agile training courses and I often preach the benefit of a daily standup. The idea is that it is 15 minutes a day where everyone in the team lists
- What they have done since last time
- What they will do today
- What obstacle or issue is in their way
It works really well in my slides but now I am trapped in the real world temporarilly working on a real project. Do I really want a daily meeting?
Read the rest of this entry »
Posted in Agile development, Capability growth, Measurement | Leave a Comment »
Posted by James King on October 3, 2011
I sometimes encounter people with the role of “producer”.
Generally I think of them as “project managers for creative people and artists” but I did once ask a producer what they really do and they succinctly described all the roles of business analyst, Scrum Master/iteration manager, project manager and product owner.
Maybe a shorter description is that they make sure everything comes together on a brief before time, creativity and money run out.
Read the rest of this entry »
Posted in Agile development, Capability growth | Tagged: agile, web producer | Leave a Comment »
Posted by James King on July 27, 2011
With certification in agile becoming all the rage, I have decided to create a new international certification for trainers.
To become a Certified Strum Muckster you need to meet the strict sounding entry criteria for the International Strum Alliance and then abide by a number of rules that have been deemed by the International Strum Alliance (currently me) to be the one true and correct way to create and deliver training courses.
Read the rest of this entry »
Posted in Agile fables, Leading change | Tagged: agile certification | 4 Comments »
Posted by James King on July 25, 2011
User stories are a great way to focus your requirements around the real needs of your users:
As a user I want to report on the number of users who read articles on my blog so I can see whether a topic is popular or not.
This approach can work really well for a production support team, but sometimes the users are listing issues or bugs, which don’t naturally follow the format. For example:
-
The current report is two slow, it needs to run in less than 30 seconds
-
Can I have the date modified to use Sydney time in Australia rather than GMT
-
The report sometimes crashes when I run it
Read the rest of this entry »
Posted in Agile development | Tagged: agile, production support, stories | 1 Comment »
Posted by James King on July 18, 2011
I have often admitted that I am not a test manager, but I know enough to realise that any project with an IT component needs to have an IT test strategy.
I also know that creating a test strategy should involve more than just taking the 25 page strategy from the last project and replacing the project name.
Read the rest of this entry »
Posted in Agile development | Tagged: agile, testing | Leave a Comment »
Posted by James King on July 15, 2011
I published a tongue in cheek article yesterday, but it left me wondering whether I believe in the value of certification.
I guess the answer is yes, but …..
Read the rest of this entry »
Posted in Agile development, Observations | Tagged: agile certification | Leave a Comment »
