David J. Anderson
"Kanban is becoming a popular way to visualize and limit work-in-progress in software development and information technology work. Teams around the world are adding Kanban around their existing processes to catalyze cultural change and deliver better business agility. David J. Anderson pioneered the Kanban Method. Hear how this happened and what you can do to succeed using Kanban."--Publisher's website.
When working in an agile team, how important is it to stick to the stories agreed at the iteration planning meeting?
If, for a business reason, a new mid-sized story needs to be added to the iteration, say 2 days into a 2-week iteration iteration, should the development team be able to accommodate the request?
Does whether you are working in an XP or a Scrum environment affect your answer?
XP is more about how to develop the software in agile way. Scrum is more about how to control development of the software. So these techniques can be easily used together.
What @hvgotcodes and @Joseph Le Brech wrote is true. In Scrum new critical request means cancel current sprint, reprioritize, start new iteration with new planning and commitment. Only product owner can stop current sprint.
If your environment demands approach where new requests can arrive during iteration and has to be solved as fast as possible you should check other agile methodology for controlling software development - Kanban. Related to your problem - Kanban defines types of "service agreements" (types of stories and their priority) and how many requests of each type can be processed at any given point in time (Work in progress limits - WIP). I recommend this book for reading about Kanban. Kanban is implementation of Lean development.
I was promoted as a project manager. To be honest this is a new role for me and at the beginning I find this job pretty hard.
Can you give me some example of metrics that I could use to measure the quality and productivity of my team members. I need to measure that for developers and for testers.
Thanks a lot, Radu
Find out why your company was interested in adopting Scrum in the first place.
If it was to produce better quality code, then you could focus on things like test coverage, bug count, etc. I like the CRAP index.
Many companies adopt Scrum because most of their problems - including low quality code, tight deadlines and rework - are caused because they produce the wrong code in the first place. Either requirements are misunderstood, or the stakeholders don't quite know what they want. If that's your problem, you might want to measure throughput (how long it takes a story, on average, to go from analysis through to release) or feedback (how long it takes you to know whether the work you did is actually usable, or not - bearing in mind that when it's not usable, you want to know as soon as possible).
I try to avoid measuring things like productivity. It's very easy to be productive without being effective. Focus on the Goal. Most of the metrics in Kanban can be used alongside Scrum and will help here. I very much like Cumulative Flow Diagrams, because they show all kinds of feedback loops and constraints in the system.
Oh, whatever you do - measure the team, not individuals. As soon as people think they are being measured as individuals, they'll stop playing nice with the team.
I am wondering, how "real" work day (7-8 hours) relates to "engineer hours" term used in estimation of the time necessary for completion of some task. I think that estimated effort in EH (if correctly estimated) cannot be simply translated into work days by dividing with 8, and that effective work day of a programmer is shorter than the time he spends in the building in which he works. This can lead to big errors in estimates when estimating small chunks of tasks (i.e. what is scope of one iteration in SCRUM) and when there are no best/worst case estimates, but planning is done based on individual task estimates done by programmers. When programmers need to estimate time necessary to do some individual tasks, they usually estimate the time from the moment they start working on it to the moment they complete it. Needless to say, it is insane to expect that someone will do 4 tasks of 2 hours each in one day.
I would like to know what are best practices in successful companies for relating effective time vs. time spent "at work" and are there some books or researches which estimate what is average time programmer spend working (focused on the tasks at hand), not doing other activities which are not included into estimate, like reading/writing mails (except ones included in estimate, if it is support task or similar), brainstorming, meeting, drinking coffee, estimating tasks and updating status in bug/task tracking tool.
If there are no books or researches, any links to articles about this issue by respected members of community will be of help also as I couldn't find any, these keywords are too generic.
Best quote ever:
“There's no sense in being precise when you don't even know what you're talking about.” (John von Neumann)
Also, experimental software engineering attempts to draw statistically relevant conclusions out of experiments in a controlled environment. Very roughly you get to design experiments applying the scientific method, choosing input variables (ie. experience of the programmers, time of the week, language/framework, etc.), and measuring the output.
The scientific method suggests a cycle of observations, laws, and theories to advance science. Experimental software engineering applies this method to software.
A good book I remember from a remarkable university class on the topic is “Experimental Software Engineering”. It assumes you have a grasp over statistical distributions and descriptive statistics, but it's a very nice read.
There are two things that we do when we program:
When we're repeating similar things, estimating - whether in points of relative effort / complexity or in hours - is usually fairly straightforward. Even when estimating in points, these can easily be correlated back to hours after a sprint or two, once the team has got up to speed.
The problem most teams face is that they're often doing new stuff. This is because:
Thus, a lot of what we do on software projects tends to be new. The usual same-old same-old frequently ends up being given to junior developers, for whom it's new.
The trouble with new things is that you have no idea how long they're going to take. You've never done them before!
I've seen a number of strategies for handling this, depending on how determined someone is to (force devs to) produce reliable estimates, how much trust you have with stakeholders, etc.
Pad the estimates horribly and then make the work fit them (this is what developers end up doing if PMs / SMs force them to produce reliable estimates, whether the devs realise it or not).
Kanban's "classes of service" allow you to mix some new things with some familiar things. This will tend to allow a less variable flow through the development pipeline, so you can base your estimates on that.
Do everything that's risky first (particularly if you don't know how risky it is!). Gradually the flow will stabilise. On a 9 month project, it took 3 months to start producing any kind of useful estimates, so careful with this one. The upside is that your stakeholders will see you addressing the things which keep them awake at night early, so trust can be high. Your PM / SM will go spare during this time. It's OK.
Accept that the old metaphor of "time spent = work done" is a myth in projects involving high amounts of learning and knowledge work. It might have been appropriate in the days when developers were treated like a factory - churning out the implementation of others' designs - but in the world of Agile and Scrum, it's completely inappropriate. Even Scrum.org have recently removed the necessity for estimation and velocity measurements from their guide. Find other ways to develop trust, manage risk, win budgets and have conversations around the work - since these are the only reasons you need estimates in the first place.
most of the books about Project Management (if not all of them) describe management of one big project. Sometimes they describe how to manage very few projects in the same time. But I have very different situation.
I manage small team (4 people) with very small projects. Usually one engineer works on dedicated project. Some times One engineer work on few projects with different priorities (projects quite often switched to "on hold" state for a several days).
So my specific is:
Can someone share own experience how to manage projects like this, or if you never had such experience but have an idea how to organize that I'll be glad to read it. Of course if you know book which can help me - I'll be glad to check it as well.
May be there is ready methodology for thas kind of projects which I never heard.