Facebook is testing introducing of system that charges $1 in order for users to contact strangers (i.e. people not connected by friendship). LinkedIn has had this kind of service for a long while, and spamming based on this service is pretty minimal. Continue reading
I knew it wouldn’t be long before Scrum came under scrutiny , and hence, in the firing line. Scrum is far from perfect, but provided some kind of transition form palatable to both business and development. Continue reading
I can sometimes go weeks, even months, having causal chats with people in workplace, without ever asking their name. Of course there is problem of when you leave it too long to ask, then it feels rude (is that just the English :)). In a way, I think it is very english – and a common problem I see in vitually every english company I have been in. If someone has a problem and doesnt speak up soon enough, the problem can just remain as long as it takes to be discovered. Which can end up months. If there is fundamental flaws in project planning, then nothing is going to go right. In a smaller/medium sized company, things may not get so bad so quick, but in a corporation … wow.
Although corporations have modernised, it is mostly a “look and feel”, none more so demonstrated by the widely loose adoption of Agile. Many corporations felt, or were sold, that Agile meant project teams could self-manage. Sure they can – if they are really being an Agile team. I would have thought assumptions at that levels were highly risky. It just goes to demonstrate there is no substitute for fully engaging the project team with continual verbal communication. And observing same principle with clients and stakeholders. Over-reliance on processes and tools goes against the core ethos of Agile, but for some explicable reason, this is what happened. Perhaps to do with perception of non-IT people – that software is akin to a machine, when you pump in requirements and out pops the software.
We have networked tools for issue reporting, planning and general communication. The social web, though a beautiful thing, created a communication anomaly, and raised people’s expectations of communication through technology. The web is in too early stages to be truly considered a communication tool, on same level as verbal communication. People are not entirely honest online, and more likely to be that way, as the web provides some degree of anonymity. We were not born with a facebook-implant, we are still primitive beings that rely on visual as well as audible communication to get our points across. You can’t avoid the necessity of face-to-face contact with clients – and on a regular basis.
A good example is on the most basic of technology – the telephone. When you are describing a situation to a client, say a problem that a new feature many cause to another feature, you cannot see the other person’s response. They may be agreeing with your every word, but may also have a puzzled look on their face, but do not want to appear ignorant. They might agree to what you say, without entirely understanding it, which is a situation that may backfire on you, later on. If you were there face-to-face, you can register people’s real reactions. In this case, you would inquire what part they didn’t understand – maybe demonstrate it if necessary. Yes, we have video-conferencing, but as you may have noticed yourself, people become self-conscious and try and mask their visual expressions.
Transparency was always going to be a big challenge for traditional business, and it’s reliance on some degrees of subterfuge. In a way, technology gave business even more tools to continue in this vein. Mistakes are a given on IT projects, but they are generally mistakes made, as part of a learning curve that exists on any IT project. Business’s inability to “go Agile”, hampered attempts of Agile implementations, because of the fundamental disparity between business and IT drivers. This problem is still widespread, and will be a while before business modernizes to the extent which IT development has. Communication and transparency – within Agile, you can’t have one without the other.
Agile is an overused term, and very rarely applied correctly. For instance, the most common dnager is in assumption that all developers are Agile. This stems from fact that most of the modern methodologies were driven by the development world.
One of the more odd flipsides of using offshore testing resource is that you end up reviewing what they have done – just to be sure. If the offshore team is providing development and testing service then the picture can become very muddy, unless there is transparency in process. An external company is far less likely to stick their hand up and say they are struggling with a bit of work.
One of the more tragic elements of this particular project was the effort made using BBD to develop feature files. The problem was the development did not follow the principle, in spite of promoting the methodology and tools. So though feature files were kept up to date, the connected tests werent. Developers simply used the feature files for reference and simply plodded on in non-unit testing fashion. the administration of BDD can seem daunting to a developer, but one you have sold up to a methodology it is sensible for all to keep to it. Depending on the company, these kind of mistakes can carry on for a long time before someone takes decision to change things, painful though it may be.
Because the offshore company failed to observe BDD fully, development soon went off-track. But instead of addressing the problem in a Agile review/improve fashion, more and more coding was done to paste over the cracks. The project quickly dissolved into a Waterfall project which necessitated full regression testing with every release.
Customers must get involved for Agile to work
In Scrum it’s the Product Owner, and it must be the single wringable neck – the person accountable to the business for the project’s delivery of real value. It is the person who not only understands, but can make decisions about functionality, business needs and the user interface.
Rather than thinking in terms of using Scrum with Kanban, it is better to use Kanban as sole approach. However, if you have a company culture that is still getting used to Scrum or another Agile approach, consider implementing Kanban to compliment, rather than replace.
There is a risk in adopting Agile, that is an historical issue not even related to Agile. The bigger a company is, the better they can suck up failure. And in a huge company, 1 project pass/fail is neither here nor there in grand scheme of things. With Waterfall (step-down) methodology, these types of failures would happen “gracefully”, due to the lumbering nature of the roadmap, and lack of visibility of progress until release points. In the larger companies, on Agile projects, something strange happens …
Give project control to developers, and you will end up with if … then … else, with no exit loop.
The phrase “The customer is always right” was originally coined by Harry Gordon Selfridge, the founder of Selfridge’s department store in London in 1909, and is typically used by businesses to:
1. Convince customers that they will get good service at this company
2. Convince employees to give customers good service
What the biggest risk in development (leaving out frightening common omission of unit testing)? That what is written down as requirements suffers a chinese-whispers style path to code. TDD was an approach to address that risk, by saying that before functional coding starts as test based on requirement is derived, then functional coding done to pass the test. Oversimplifying the nuts and bolts, but that is general idea.
[In TDD] first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.