How do you schedule tasks in a project?
How do you decide what tasks to schedule first: the complex ones or the easy ones? the short ones or the long ones? the risky ones or the sure-shot ones? Most often, this task sequence is determined by hard logic, soft logic, or some other external constraints. However, how do you decide when there are no such contraints? If we look at the risk driving the project lifecycle and scheduling, then it is natural to expect high-risk tasks being tackled at the start just so that we are systematically driving down risks in the project and achieve higher certainty levels as we get close to the project. However, it seems inconceivable that someone will cherry-pick the easy tasks first and leave all high-risk ones for the end! Clearly, that is setting up the project for a grand finale of...
Codifying Agile Skills or creating more checklists ?
Did you check out the Agile Skills Projects yet ? It seems to be a new and interesting initiative to “… establish a common baseline of the skills an Agile developer needs to have, including a shared vocabulary and understanding of fundamental practices”. They talk about Agile Skills Matrix that has seven essential skills, or the Seven Pillars, organized into five skill levels. Seven Pillars include: Like this:Like Loading......
Do you follow Project Management ‘religiously’ ?
Project Management is perhaps one of the most fiercely debated and grossly misunderstood disciplines in the software field currently, hence let me throw in a disclaimer first: if you are a small team of experts and/or people well-known to each other (e.g., have worked together as a team earlier), and situated in a collocated fashion, doing a lot of ‘creative work’ that can’t be very ‘accurately’ scoped, let alone managed; you probably will find ideas of formal project management a huge overkill (on time, effort, money and might even seem to stifle creativity), and you might be better off considering ‘lightweight’ methods like Agile Project Management / Scrum in the context of software development (well, nothing stops you from deploying pieces of Agile / Scrum in a non-software context - it is based on common sense after all). Small...
Blame your “flaccid developers” and your “flaccid customers” for your poor quality products !
This is the text from a recent announcement for a course by Ken Schwaber on “Flaccid Scrum - A New Pandemic?” (text underlining is mine): Scrum has been a very widely adopted Agile process, used for managing such complex work as systems development and development of product releases. When waterfall is no longer in place, however, a lot of long standing habits and dysfunctions have come to light. This is particularly true with Scrum, because transparency is emphasized in Scrum projects. Some of the dysfunctions include poor quality product and completely inadequate development practices and infrastructure. These arose because the effects of them couldn’t be seen very clearly in a waterfall project. In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint. Like this:Like Loading......
PRINCE2 handles Project Tolerances better
Most project management frameworks and methods advocate (and actually require) ‘point-estimates’ in planning and scheduling. By ‘point-estimates’, I mean there is a ‘hard number’ that seems to be etched in stone, leaving with no ‘tolerance’ or ‘leeway’ for the project manager and his team. Even though we all understand that estimates are never point-estimates (and hence the project commitments are never a point-commitment), we still expect a firm estimate (and consequently a firm commitment) from a project manager. For example, a given feature must be required by 23-June, but there is no recognition of the fact that 23-June might still be a couple of months away, and several things could go wrong or could change meanwhile thus affecting the validity of this date. In real-life, there are always tolerances, some allowable, some acceptable, some tolerable and some simply unacceptable. This is not limited to...
Nice video on Waterfall vs. Agile…
httpv://www.youtube.com/watch?v=gDDO3ob-4ZY Like this:Like Loading......
What is the Inventory of your Software Development project ?
 Like this:Like Loading......
Applying Little’s Law to Agile Project Management - Part 2
Second part of my article on exploring how Little’s Law related to the Agile Project Management just got printed in PM World Today. Here is the abstract: Little’s Law states that inventory in a process is the multiplication of throughput and the flow-time. In first paper of this two-part series, we took an every-day example to discuss Little’s Law at length. We also briefly looked at the implications of Little’s Law for manufacturing and for software development. In traditional manufacturing, there is a strong emphasis on plant capacity utilization as a core driver in cost management. However, a high plant capacity utilization requires (or rather leads to) high inventory to ensure the production doesn’t slow down for want of raw materials. High inventory in turn leads to a low inventory turnover, signifying poor sales, thus having high economic implications. Inventory is...
Is Scrum serving your Software Development, or the other way round ?
There was a question on the group Scrum Practitioners on LinkedIn if “…implementing Scrum as a whole should be our goal or would you use aspects of the Scrum methodology to realise an agile culture change ?†Looking at the disproportionately large number (with an increasing trend) of posts on popular mailing lists on Scrum and Agile software development, I am alarmed that most energy and thought is being spent on figuring out “how Agile you are”, how should the user stories be worded, and whether one uses planning poker or not ? I mean…does it really matter whether you use ‘deal hours’ or ‘story points’ whatever that means ? If your team members are not speaking out ‘impediments’ in daily scrum…come on…that was the case in good old days also…expecting that Scrumifying the process will make everyone speak...
Whatever I know about Scrum, I learnt from my sixth-grader son, and Scrum can too !
Scrum offers a fresh approach of software development. However, the philosophy itself is not entirely new. It has been around in various disciplines for quite some time, and it is only now that the software community has woken up to it. I found an everyday example of my sonss full academic year as a great way to explain Scrum to someone new to it. My sixth-grader son (“Scrum team“) has a bag full of books (“Product Backlog”) that the teachers (“Product Owners”) must complete in the given academic year (“Project Schedule”). There are various subjects (you may call them sub-systems, component or modules if you like), and each subject has one or more books, each having several chapters (“Sprint Tasks”). To a great extent, the books don’t change in the middle of an academic year, though some of the...