 | |
| Traditional Project Management Vs. Agile Operations Management |
Technology professionals are embracing Agile principles and enjoying the benefits of low ceremony methodologies such as SCRUM. When you work with a team to provide configuration management services or even DevOps, you need to have a good understanding of the underlying software methodology.
Popular wisdom suggests that Agile is better than waterfall as a methodology which is known for being verbose and inflexible. But the truth is that I believe that many companies are really moving away from waterfall little more than a myth. Many companies are typically embracing a Hybrid or Agile Project Management approach and embracing practical methods such as LEANs focus on limiting the amount of work in progress (WIP) which has been shown to yield better results.
Download Also:
In many ways project execution and product delivery are transforming from being “Scope driven” to “Time bounded”.
This is best understood from the remarkable success that teams experience when embracing scrum and time box sprints. This transformation is focused on assessing the WIP with time bounded execution, but otherwise keeping the waterfall process steps as-is. Software development focuses on creating products or services which are offered by an organization with the anticipation that they will satisfy customer demands. I view products as being a proactive solution and services more often being reactive and meeting a customer requirement or solving a problem.
The Waterfall methodology helps me to think through my customer requirements and deliver solutions which delight our customers. To really understand how to use waterfall, you need to understand it assumptions and methodology.
Waterfall - Software Development Process
The Waterfall model [1] is a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production deployment, implementation and ongoing maintenance.
In my world, any product or service developed must go through this process steps. The waterfall methodology does not require a specific project size and it also does not have any specific requirements for documentation of artifacts such as requirements, test cases and operations runbooks.
The amount of documentation is really mandated by the organization when they want to comply with frameworks such as the capability maturity model (CMMi) or standards such as those created by ISO, often in response to regulatory requirements such as those mandated by HIPAA or to scale (knowledge being transferred from individual to documents). Organizations with regulatory requirements may choose a Project Management model to ensure that they can meet these demands.
PMI - Project Management Framework
The Project Management Institute (PMI) provides guidance that helps in standardizing the project delivery execution for any Industry by defining the project delivery framework. The PMI views a Project as a temporary endeavour undertaken to create a unique product or service which helps to clear expectations as to when delivery will be completed. With this approach, all tasks must be expertly managed to deliver the on-time, on-budget results along with the documentation and integration with operational processes that organizations require. Every project may be unique in many ways, but still an outcome of a specific set of operations. The work break structure is more aligned to waterfall process such that it is much easier to predict the operational cycle time ( manufacturing ) and mostly importantly when the completed system will be delivered.
In the technology field, the predictability of the being on-time and within budget is not reliable. I have not seen any software delivery projects complying to that definition. Projects are typically focused on the scope and delivery of the requirements on the user's wish list, at least in the initial stages. The scope will keep on changing based upon customer feedback and knowledge gained during the course of the development process and that is where the unpredictability comes. Business drivers and other factors ( like unknown technology application ) may be the root cause of project delays. Somehow this problem has been associated with “waterfall” projects.
Agile Principles and Scrum Framework
The Agile Manifesto [2] notes that we value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
There are 12 principles from which the Agile manifesto is derived. I have always suspected that the Agile Manifesto evolved from the IT Services Industry and especially as a result projects that were billed based upon time and materials. I know that this is an unusual view so let me explain my rationale. Software products are often sold based upon licenses for a specific set of users, whereas when the software is developed for a specific customer the terms are usually specified in a statement of work (SOW).
Contracts are usually negotiated as part of this effort. Service oriented projects are often quoted as a fixed price or based upon time and materials. The scope of the project is usually fixed when the price is negotiated and the SOW and contracts are signed. Fixed price projects make it very difficult for software teams to respond to change and make changes to the project scope and hence traditional Project Management may be a better approach for these situations.
The Agile Manifesto is more appropriate to T&M Projects when the scope ( / requirements ) is not clear. Product Development that is outsourced will fall into this category. In these situations, Scrum is one of the popular Agile principles implementation framework that has provided guidance on how to do software development based on the guidance found in Agile principles. In fact, I think many people refer to Agile when they are really referring to the scrum framework. It is more development focussed.
Release Management of Product or Project is much more than development. Here are some things to consider. Agile scrum is usually used by small and medium sized teams. The Scaled Agile Framework (SAFe) and Large Scale Scrum (LeSS) are more often used for larger teams. Similarly the Enterprise Service Planning (ESP) which is the the Kanban [3] equivalent of the SAFe. Scaled frameworks can be considered to Product or Project delivery and even they are more focussed on development.
Organizations looking to achieve Enterprise Agility must typically identify and define the release unit. It could be a small story ( or defect) , single feature (multiple stories ) , set of features. You have more 20+ industries where software is heart. And you have different portfolio of products ( each has its own set of requirements ). Each industry like Healthcare, Clinical Trials, Aviation Industry are absolutely different.
Release Unit and Cycle time of that release is completely contextual. In my opinion, Agile is difficult to adapt in many organizations and they must really use a Hybrid project management approach. When you work in configuration management and DevOps you need to understand these approaches and align your work with the methodology that is required in your organization.
To achieve Enterprise Agility organizations need effective DevOps and Application Lifecycle Management (ALM) processes and tools along with a culture that is disciplined and capable of code components developed in parallel. In practice these projects ( Agile Scrum / SAFe / PMI ) must still go through what is essentially a waterfall process steps. I feel there is no escape to waterfall process steps even after adapting Agile Scrum ( instead of PMI Projects ) … Let me know your opinion about what is really happening in your organization!
Sources :
- https://en.wikipedia.org/wiki/Waterfall_model
- http://Agilemanifesto.org
- https://theAgileist.wordpress.com/tag/future-of- kanban
- https://ullizee.files.wordpress.com/2016/05/scrum-development-process.pdf
- https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
- Agile Project Management: Best Practices and Methodologies
- Download Beginner's Guide to Agile Project Management
- You will not become agile by implementing scrum
About:
Specialist in Software Delivery and IT Operations. A generalist in Business Operations; an Intrapreneur ( Proactive, Adaptable, and Balanced ), who have built products ( / solutions ) and sold them apart building solid scalable teams. Overall 17+ yrs exp. Worked at GE (~8yrs) and working in Addteq (from last 8 yrs). Started as a first employee and currently working as BU Head (owning P&L). Exp in various functions. Product Engineering, Project/Program Mgmt ( Products, Services [ outsourced, delivered ] ), Consulting, Presales, Product Mgmt, Sales, Marketing, Strategy, Service portfolio. Few of my traits
* Always believe in learning. Life long shall be a student.
* Simplify complex tasks (with basics / fundamentals approach).
* Good at operatilizing ( 0 to 1 ), optimizing and scaling
* Very Candid in discussions.
* Enable the team members ( and sometimes customers as well ) to think.
* Believe in Systems. There is a method to my work.
* To improve quality, naturally see inefficiencies, errors and problems.
* Strong in application of a theory learnt ( ex: Ops Mgmt theory to Team Productivity )
* Have very different perspective
> Every team/function is like a manufacturing unit
> Process is like Friction. It is an enabler (than an overhead) if used appropriately.
> There is nothing called as Agile / DevOps culture
> Agile Manifesto is not meant for Products, Scrum,SAFe frameworks are not meant for Services
> There is no single DevOps product.
> Scientifically measuring team productivity is not yet established. Without a baseline all the ROI for improvements (claims) are incorrect.
Post a Comment