Agile operations is about a mindset as much as any technology. Ironically, the most agile teams that decree agile loudly are really agile
from Web Operations
Agile
All posts tagged Agile
Agile ostensibly focuses on improving communication and the flow of ideas, but when that focus is lost, Agile can become a excuse for falling to communicate, especially at perceived process boundaries.
from Web Operations
Image via Wikipedia
A very interesting, vivid and beneficial presentation!
The purpose of the presentation is to illustrate “how” to scale lean and Agile across multisite. It presents practices and tips related to adoption of offshore, multisite development and coordination within large scrum teams.
I liked that fact that was presented at the beginning: “big projects” can be broken down to smaller projects. Large project are most of the time based on wrong assumptions. So before thinking of scaling think of breaking down the project into smaller projects.
Image by jremsikjr via Flickr
Estimation is a guess-work. Hence, when we estimate an iteration, there is a possibility to not being able to finish all scheduled features.
Not a big deal! Extend the Iteration! Not exactly. Extending the iteration is one of the worse Agile anti-patterns1. It is never ever a good idea to extend your iteration.
Below are a list of tips to continuously complete your iteration:
- Keep your hands in tasks while your eyes on iteration! Never get very focused on the completing tasks without reviewing the status of the iteration everyday
- Use priorities: Engineers usually tend to work on things they find challenging first! Over come this and get things done according to business priorities. Ending the iteration with 3 low priority features is wiser than ending low priority tasks and leave one of the high priority tasks undone. Continue Reading
Defined by CollabNet ” Scrum is a management framework for incremental product development using one or more cross-functional, self organizing team of about seven people each. Scrum provides a structure of roles, meeting, rules and artifacts.”
By definition,Agile is a a mind set, as well as, a set of engineering practices for rapid delivery of high-quality software, as well as, a business approach that aligns development of customer needs. Scrum, as well as, other Agile flavors are great for product development.
However, claiming that Agile – or any of it’s flavors – eliminates the need for a project management methodology, I believe is not precise . Agile was not intended to replace project management Continue Reading
Customers usually ask: how much? and how soon?
It is inevitable to have answers for those questions. Especially when bidding for projects, Project Managers usually need to estimate even when they have no complete requirements document and no signed-off specifications.
Even for internal projects, it is usually hard to get senior management commitment without having at least an order of magnitude estimation for time and cost.
Can Agile answer those questions? Can Scrum?
The best IT project management articles on TechRepublic in 2009
20 cynical project management tips
Very ironic yet realistic facts about project management. You’ll enjoy reading them.
Agile project management: Estimating the unknown
An excellent article to answer the dilemma of budgeting and time-estimating for the entire project, which is taking against agile methodologies as a shortage and unrealistic approach. Very interesting perspective that provokes a lot of idea. I should be blogging something in light of them.
Managing innovative projects: Don’t mistake the map for the journey
Another eye-opener from Rick Freedman . A very interesting reading that ,definitely worths to be on the list, illustrates what project managers should really concentrate on and care about. It also illustrates why Agile approaches are appropriate for creative and inventive projects.
Is your project a real project?
Back to the basics! what distinguish projects from other forms of work. With all respect to the writer and TechRebuplic list compiler. I believe this blog shouldn’t have made it to this list, it’s very basic and it’s found in the first few pages in PMBok
Three reasons to have a post implementation project
Illustrating the scenarios/benefits of planning.conducting post project review. This is a valuable blog, however, I believe post project review is not the responsibility of the project manager. Using PRINCE2 terminology, The Post Project Review is conducted after the project has completed. It is to evaluate if the Business benefits, as defined in the Business Case were achieved. It is not part of the project or project products. It’s just planned and presented to the Project Board to confirm project closure. Again with all respect, I believer this blog shouldn’t be on this list.
Finally, I believe only 3 out of 5 deserve it to the top of 2009 list. Let me know what do you think
FDD vs SCRUM
“At Bayt.com, we had opted to use FDD. While I believe that SCRUM, as all other agile methodologies is excellent in supporting human-oriented software development environment, I continue to believe that it lacks well defined control points (milestones) that are required to track the progress of features implementation. It is clearly focused more on the Project Management side rather than the Software Development side”.
That’s was part of my answer to a question a friend of mine – Husam Saqallah2 asked few months ago. He wanted to know my opinion about SCRUM and how I do compare it to other methodologies, What is the purpose behind SCRUM popularity, while most of the feedback he is getting from PMs Working on big projects was not positive? why more companies are asking for SCRUM experience and who is behind that move, developers or executives?
His question sent me 2 years back in time, where I had to decide on an Agile development methodology. I did an intensive research that drilled down to choose between SCRUM and FDD. I have to say, it was not an easy decision to make, both seemed relevant and practical. Finally FDD won the race for the following reasons:
- FDD has well defined control points (milestones) to track the progress of every task. Those control points (Walkthrough, Design, Design Inspection, Coding, Code Inspection and Promote to build) serve the following purposes:
- help project manager to track the progress of every task (feature)
- provide developers with a very clear flow of each task (feature) implementation and, at the same time, provide interaction client (Walkthrough) and other team members (Design and Code Inspections.
- FDD has clearer concentration on quality, though it is not modeled as a role but as a function continuously carried out by different parties involved in FDD; hence I can claim that the possibilities of having a quality product are higher with FDD. Design Inspection is a proactive quality activity to make sure that the feature will be implemented properly while Code Inspection is a reactive activity to verify the implementation. Both help to produce higher quality and avoid rework.SCRUM on the other hand does not highlight details or milestones for every feature implementation
- SCRUM overlaps and/or partially covers some Project Manager activities, which as a project manager, is something I do not like. For Project Management I prefer to use a more mature methodology like PRINCE2 – Which I believe is a perfect match of iterative and incremental development methodologies. FDD on the other hand, concentrates more on the implementation/development side at a lower level. Coupling PRINCE2 with FDD worked like a breeze without any confusion or misunderstanding of responsibilities.
FDD was more appropriate for the situation, the context as well as, my personality! That does not necessarily mean that FDD is absolutely better, SCUM cannot produce quality products nor always fails. Though I have my conservations and concerns about SCRUM, I found the feedback my friend collected from Project Managers is biased and we cannot blame SCRUM for this.
I believe any software development methodology will fail at that level, as they are not supposed to be responsible of this – though I blame SCRUM or any agile software development methodology guys for claiming that their methodology can handle big projects by their own. Handling big projects requires advanced project management techniques and approaches. Such projects should be undertaken as a program, where project is split into multiple modules/sub modules that can be managed as separate projects. Separate projects can be executed with SCRUM – or any other methodology -, while coordination between projects is done on program level.
Finally, I believe we should not overlook the importance of the human factor; a methodology might not fail because it is not mature, practical or verified, but because you haven’t secured the buy-in of all participants. Getting stakeholders acceptance to the cultural change you are proposing is one of the most challenging – if not the most– factor is the success of any process or methodology.
Who is behind SCRUM? Honestly, I am not sure, but what I am sure of is that it is there for a reason, same as FDD.
1 FDD stands for Feature Driven Development. One of the Agile software development methodology.
2Husam Saqallah is a friend and the CEO of astroClipz, Inc.
At Bayt.com, we had opted to use FDD. While I believe that SCRUM, as all other agile methodologies is excellent in supporting human-oriented software development environment, I continue to believe that it lacks well defined control points (milestones) that are required to track the progress of features implementation. It is clearly focused more on the Project Management side rather than the Software Development side
Understand terms before you add them to your terminology arsenal! I believe we should all abide by this golden rule. Not knowing about a technology, science, trend or concept, is better than having a wrong understanding of it.
Working in a discipline like IT, I hear a lot of jargons, terms and idioms and having good relations and interactions within the IT medium; I am consistently noticing terms misuse. Hence I decided to start a new series in my blog: Misconception.
It is very common these days the use of “Agile” to describe any iterative software development process or methodology, which is a flagrant assault and bold underestimation of Agile.
Agile, is way beyond that. In addition to being incremental and iterative, Agile encourages frequent inspection and adaptation. It is a project management and leadership philosophy that encourages teamwork, self-organization and accountability. A Set of engineering best practices for rapid delivery of high-quality software and a business approach that aligns development of customer needs.
Agile, is concerned with building high-quality software in small iterations. The progress of the project is measured in terms of features and working software. Customer involvement is vital for any project success.
Agile is not a single methodology or process. In fact it is a family of development processes including, but not limited to: Feature Driven Development (FDD), SCRUM, Lean Development and Extreme Programming (XP). However, the main principles behind them remain the same:
-
Individuals and interactions over processes and tools
-
Working software over comprehensive documentation
-
Customer collaboration over contract negotiation
-
Responding to change over following a plan
It is worth mentioning that Agile is behind a lot of success stories in software development history. I have personally achieved some of them, though they might not be mentioned in history 
. However, wise project managers know that there is no silver bullet. As project managers our judgment on choosing the most appropriate methodology plays a big role in projects success.
