Skip to main content

Is Agile Project Management even an an appropriate term?

To give you a break from my silverlight and WPF babbling I will branch out occasionally into different topics to keep you interested and at the same time tone down my boredom from talking about the same topics again an again.  As the title suggests lets explore if "Agile Project Management" is even an right term that is being so loosely used these days.. To understand we need to first answer what Agile software development is?.

Agile software development has it roots in OOP (object oriented programming) where iterative development, use of a particular functionality could be reproduced, ability to plug in cross-functionally or design development methods for re usability of components could be done in an easily gave rise to the practices of agile software development into being.  This was extended across development teams for collaborative purposes during development or the life cycle of the project. Agile software methods break tasks into small increments and avoid long term planning, time frames are shrunk to a max of four weeks for a set of tasks to be completed which may involved requirement analysis, design, coding, testing and acceptance of that stage. Documentation is produced all along with those activities happening in tandem.

Usually in an agile software development team members usually come from cross-functional expertise and because hierarchal power structures aren't present decisions are made quick and responsibilities are assigned for development, changes, bug fixes, and releases. The team's size can vary from five to ten people but larger projects are usually comprised of such teams collaborating in real time and often Agile software development  then becomes a daunting and challenging task. However these days we have measurement metric softwares that measure the progress of each task on each day by which Agile development becomes easier. So coming back to the question I posed to mix the terms Project Management (PMP) and Agile Project Management wouldn't be right as they both address management of software development life cycles differently, they have different methods and practices. Traditionally Project management adopts the 7 step or waterfall approach the Agile software development uses methods like Agile Unifed Process (AUP), Agile Modeling, Agile Data Method, Scrum, Extreme Programming and while its practices consists of Test Driven Development (TDD), Behavior Driven Development (BDD), Pair Programming and the RITE method. I may explain each of these methods or practices some time in the near future.

I am sleepy now...some more about this in the far future.

Sam Kurien

Comments

Popular posts from this blog

IT as a Innovation Partner in Business

Usually in Business organizations and especially in organizations where R&D is a separate department itself a tension persists on keeping the IT department away from any decision when it comes to innovation or process improvement. In short the IT department is generally seen as less of a help and more of a hindrance to innovation efforts. One of the main reasons is traditionally information systems are designed to impose structure on process, achieve pre-defined goals, produce metrics and minimize need for human interaction (in some case over maximize human interaction leading to nothing but "meetings").

While Innovation activities are highly unstructured and emergent, IT cannot be ignored or kept in isolation because IT can help in visualization tools, data mining efforts, uncover hidden relationships between data and create tools of knowledge management/information repository that so desperately is needed cross functionally but especially by the innovators within a org…

Analysis of SAP’s Platform Strategy

The software industry has been through high and lows up with the constant advent of new technological innovations and rapid changes in the global economic landscapes. SAP is the leading enterprise application software giant started by Hasso Plattner. The rise of Enterprise application industries started in early eighty’s with organizations needing one single software program that was capable of serving the multiple needs and functions of various departments. One single enterprise-wide application software means integrating applications that fused together for the smooth exchange and extraction of information. For example when customer services sold a product and got stock updated in the inventory by the warehouse people and the same data could be pulled by the Finance department. Enterprise Application software’s were designed exactly to do the latter mentioned processes seamlessly. SAP started by break away engineer’s Plattner and group build the company on strong engineering fort…

How Dashboards can mislead

Read an interesting article from John Shapiro professor at Northwestern Kellog on how dashboards can mislead executives and I cannot agree more. To be honest, I love visualization of data and have pushed my data architects and report writers to give me snapshots of various measures but how often the rich data didn't mean anything as it did not align with organizational goals. Even more, what information is important to me is not necessarily relevant to other executives in the organization.  Data analytics visualized on dashboards typically describe existing measures on past phenomena, some better ones predict future events and past data and the best one prescribe a course of corrective or strategic actions.

Shapiro talks about three types of traps executives can fall for:

1. The Context Trap:  We equate empirical data to the objective. I have blatantly used the cliche "numbers don't lie." But this belief can be dangerous because we can track wrong measures or metrics…