Dear Junior
I have seen quite a few classically managed projects, and through friends and collegues I have been in contact with even more of them. I would just like to make two observation on the practice of working
overtime in different phases of such projects.
* It is very uncommon, actually I have neither experienced nor heard of, that project management orders overtime for requirements analysists so that they will deliver the full and finished requirement documentation on a specified date.
* It is very common, actually I have experienced it several times myself and heard of it numerous times, that project management orders overtime for programmers so that they will deliver the full and finished implementation on a specified date.
From these two observations it is probably possible to deduct lots of interesting conclusions. I will refrain from doing so here and leave it up to you as an interesting mind-game.
Yours
Dan
CommunityHack i Göteborg
3 months ago
The type of project management you describe rarely results in a successful outcome. For this and others reasons, anyone finding themselves in this situation should really evaluate their options.
ReplyDeleteDear Junior,
ReplyDeleteI'm a tester, and... oh, never mind.
Yours,
---Michael B.
Dear Jeremy
ReplyDeleteI agree, I find that organisations with traditional management often lack in respect of their co-workers. This in stark contrast with companies like WL Gore and Assoc which are founded on a completely different outlook on people.
I find your advice for people in these situation to have a look around a very wise one - developers who care for their job are sought for by more than one company.
Yours /Dan
Dear Micheal
ReplyDeleteI have understood that in traditional projects testers have a really ungrateful position - my deepest sympathy for the lack of esteem of an important and difficult job.
It seems to me the situation in agile is better with less hand-offs, closer collaboration during sprints, and techniques like exploratory testing that embrace that testers are intelligent, learning, curious, and creative people.
Yours /Junior
Dear Junior
ReplyDeleteYou mentioned that you had a some correspondence with a tester Michael regarding our discussion on overtime, and that you had mentioned exploratory testing.
To verse yourself in that field, I would really recommend you to check out the works of James Bach and Michael Bolton. Start with their blogs found at http://www.satisfice.com/blog/ and http://www.developsense.com/blog/ respectively.
Yours /Dan
I think this phenomenon is about how tangible or concrete the artifacts are. It's very easy to try and feel implemented software and therefore complain about it being incomplete or flawed. Requirements, whether in a requriement spec or in an agile backlog, are much less tangible and therefore hard to judge.
ReplyDeleteIn the light you shed it's even more chocking how product owners wine about having to spend time with the backlog and sprint planning every two-three weeks.
Dear John
ReplyDeleteYou definitely have a point there. It is harder (not impossible) to define a "definition of done" for requirements, thus there is a risk to let that work linger on.
The only requirement DoD I have found is to let the development team decide if they find it scoped and detailed enough. This is of course best combined with an agile approach where requirements find the most important story, which is handed over for development. In parallel, requirements continue to search for the next now-most important story.
To no big surprise, a product owner of the kind you mention is far too distant for my taste. I expect the PO to talk to the team daily. Someone reluctantly showing up once every second week has clearly misunderstood the role.
My advice for an organisation in that situation would be to look for someone else to take on product ownership.
I will return to my view on and experience of product-ownership in another letter.
Yours /Dan
I am in the final stages of a project and we are discussing how to put positive pressure while increasing engagement in the scrum-team.
ReplyDeleteBecause this is my first real experience with agile techniques it will be interesting to see what will happen the next few weeks.
Dear Olle
ReplyDeleteSorry for a slow reply.
The final stages of projects (close to the deadline) is often a water-test in what you *really* believe in. Even if you believe in self-organisation and inner drive as the best way to high productivity, even then it is sooo easy to slip back into some command-and-control mode to "ensure things get done". And that will ruin more than it helps.
It is a little bit the same frustration as trying to put an unwilling child to sleep. After some hour or so, it would feel so good to raise your voice and command: "Now go to your bed and sleep! Immediately!". But that would of course be just contra-productive.
There is nothing wrong pointing our that "we trust, really trust, that you will do your best - and we trust you so much we will not command you what to do or how".
I think you are really on the right route talking about "increasing engagement" and I really hope you and your team will see success in the close future.
Yours /Dan