Avoid Gold-plating Through Agile Delivery
By Kiron D. Bondale
As it is with jewelry, on projects gold-plating is all form with no substance. The increase in costs is rarely justified by the value provided by superficial “bling”.
It could be an analyst adding in requirements which they came up with on their own without ensuring that those are actually required, a developer who introduces a code change or feature they believe is useful without checking with others or a quality control specialist who decides to test above and beyond approved test plans.
Don’t get me wrong – the intentions are usually good and I’ve yet to encounter an instance of gold-plating which was done maliciously. But it doesn’t matter – gold-plating is work creep.
What’s the worst that could happen you ask?
On a project which follows a traditional or waterfall delivery approach, that innocent feature which the developer added might cause regression to approved functionality but at the very least when it finally gets identified will generate unplanned work for other team members. Read the Complete Article
My Journey with an Agile Project
By Seshadri Sounderrajan
The purpose of this article is to share my experiences with the deployment of Agile methodology based on the project I am currently associated with. Although Agile projects do not have a rigid hierarchy, Project Managers have a significant role to play in the context of managing multiple parties with varying expectations and non-negotiable deadline. This article does not offer a prescriptive approach as methodologies such as Waterfall and Agile are context/environment specific with its own set of pros and cons.
I am handling a project in ABC Bank (for purposes of confidentiality I would refrain from disclosing the name of the bank in Singapore) which involves integration of insurance platforms with one of the largest insurance providers in the insurance space. As is the case with huge projects, region-wide initiative encompassing multiple business entities with myriad technical platforms and the rigid business processes has plethora of challenges. Read the Complete Article
Reinforcement for Running Retrospectives
By Kiron D. Bondale
Retrospectives are a common, regularly practiced ceremony on projects managed using an agile delivery method.
But why stop there?
There’s no reason that retrospectives couldn’t be applied to traditional projects too, it’s just that some improvement ideas might not be immediately applicable in a non-iterative lifecycle.
But won’t it cost a lot more effort to conduct regular retrospectives rather than waiting till we get to the end of our projects? To defuse that concern, here are some reasons why retrospectives are superior to traditional lessons learned approaches.
We all want to help our company but charity begins at home! Why wait till the end of a project where the only beneficiaries of learnings will be teams on future projects if there is an opportunity to reinforce good practices and course correct on others to the benefit of your project?
Sharing knowledge is a good first step, but actually applying that knowledge is when we now whether the lessons are valid or not. Read the Complete Article
5 Reasons Why Agile Project Management Is Important
By Frank Mud
With organizations aiming to build work environments that promote flexibility and client satisfaction, there’s a host of brand new management techniques which are being applied to various projects across different industries. One strong trend in management is agile project management, which is based on values such as productivity, adaptability and collaboration.
Since agile management lacks that type of formal structure offered by other management styles, it relies in a high level of internal discipline and team coordination to ensure the achievement of critical business goals. Here are 5 good reasons why agile project management might become a key standard for the future management practices.
Read the Complete Article
- It boosts speed-to-market
Agile management is all about early and regular releases. This type of perpetual beta approach makes the strategy so efficient because it focuses on getting higher revenue from incremental delivery, effectively helping the team to quickly bring a product to market.
Bringing Agile Into the Portfolio
By Nils Davis
In today’s tech infused world, many companies strive to rise above the competition and get results from their efforts and ideas as quickly as possible. It’s okay to want instant gratification – our customers seem to expect it – but as we well know, anything great takes time. But shaving even small amounts of time off valuable projects can yield big returns. So how do you compound that and make it a habit? Some ideas and principles from “agile” promise to get you there.
What Is Agile?
To explore the application of “agile” to portfolio management we need to start from “what is agile?” and why it’s effective at driving value. I’ll generalize some of the concepts you are probably already familiar with from agile development methodologies, and then tie those into portfolio management.
Agile does not equal scrum or kanban. Scrum and kanban (and others) are methodologies for applying agile principles. Read the Complete Article
Agile Baby Steps: A Parable To Help You Get Started
By Rob Kraft
We often hesitate to take the action that shows we are committed to doing something new. We read about it, analyze it, and try to understand it; but real learning requires that we go beyond reading. We must DO. The goal of this article is to get you to take action toward becoming Agile, without understanding or adopting all of the habits of an Agile development team. I am asking you to try out some new processes in your software development life cycle, without considering whether or not you are doing Agile development.
Side bar: Your ability to implement an Agile technique depends upon the process by which your software is implemented. An Agile development technique that works for one process may not work for another, so be cautious of Agile recommendations that state you must do something specific or you will fail at being Agile. Read the Complete Article
The Great Delivery Debate
By Chris Moody
Dr. Winston Royce first described a model for working with large software systems in 1970, which we’ve grown to know as “Waterfall”. Interestingly enough what many never read in his writings on software development, is the following quote: “I believe in this concept, but the implementation described above is risky and invites failure.” (Source: Dr. Winston Royce. Proceedings, IEEE WESCON, August 1970) Why could he have said this? Could it be that many times requirements are emergent? Perhaps it’s that estimating large and complex bodies of work based on a requirements document can be incredibly inaccurate?
While I have a large bias towards Agile methodologies, as a consultant it’s my responsibility to evaluate what truly is the best solution for a client. I was recently on a project in a marketing organization, and while there certainly were some opportunities for Agile principles to be utilized, a framework like Scrum or Kanban just would not have been possible. Read the Complete Article
I Want to Use Agile, but My Organization Doesn’t Want To
By Chris Moody
Fear not agile warrior, you are not alone and help is on the way. They are many situations where someone just knows that agile could help or even change the face of the entire company if utilized…yet someone or many people within an organization are opposed to the idea. So what should you do? First off what are some reasons someone would be against agile?
- The’ve been on a team where agile was used, and failed.
They don’t know enough about agile or have misconceptions.
They don’t believe agile is right for their organization/product.
They’ve worked with an Agile Coach/Scrum Master/Consultant that was not very good at their role. Yes, not everyone does their job well…even in the wonderful agile community.
They are from the past (I kid…I kid! That was an IT Crowd reference)
Now for the part you really came to this blog post for: What are ways I can help my organization adopt and/or support agile? Read the Complete Article
Six Predictions for Project Portfolio Management in 2016
By Kevin Kern
Each year we review and reflect on some of the industry specific Project Portfolio Management trends of the past year and consider trends for the coming year that might have an impact on the business. Here are our six predictions heading into 2016:
If you’re not managing your applications, they’re managing you.
Applications are powering business. Application ecosystems are everywhere, and steadily increasing. Paradoxically the continued reliance on applications isn’t being managed or tracked proportionally to the level of importance we feel they deserve. Applications are changing the way businesses operate and optimize, yet in so many firms, they are being tracked on spreadsheets. This is the age of application software, or as I call “the post PC era,” where nobody cares about the operating system or hardware. We believe the consumerization of IT will continue.
We don’t discount the importance of application maintenance and repair, and this includes application configurations and customizations that make business process incrementally better for all your team members. Read the Complete Article
Benefits of an “Agile” Mindset
By Perry McLeod
Projects are a social endeavor. Traditional project management approaches have shied away from the social advantages a more agile project environment brings. By nature, we are storytelling, pattern seeking and social people. We need colocation to shine truly in a project environment. Agile is about creating and fostering a culture that has:
- responsible stewardship
- individual empowerment
- open and transparent communication
- self-organizing, self-determining, collocated groups
- knowledge sharing
- consistent face-to-face interaction with customers and each other
In a waterfall environment, resource management is always an issue in any project. Especially when the stakeholders have operational duties to perform. If our requirements team was 100 percent at our disposal, always completed activities on target and worked a full eight-hour day without distraction or a loss of productivity, then estimating time would be simple. This is never the case, however.
Command and Control Organizational Structures
Many business analysts, project managers and other project team members such as subject matter experts(SMEs), customers, users and other stakeholders classically work in a functionally organized environment. Read the Complete Article