Methodologies – Godinterest

November 15, 2015July 1, 2022

Taking the Right Path to Good Agile Implementations

1) A Wise Man Said Only Fools Rush In

Companies that goes nuts for agile because they know they have to deliver faster and for less cost to keep up with competitors may be making a big mistake and face a collapse of their efforts.

If they focused first on a deep understanding of their business’ needs, they could more accurately decide if agile is a good fit. A better approach for you to take is analyse your current processes to determine if agile methodologies actually support your goals and needs.

2) Educated Stakeholders Make Excellent Allies

Agile works from a focal point of improving quality delivery and frequency. It does not start with reducing time to market or cutting costs. Those benefits are a result of implementing agile methods over time, after the requisite investment of time and resources has been made.

3) Don’t Do the Project Without at Least One Committed Product “Owner”

A “product owner” is a the committed business leader who will make or break the project. This person will be expected to put at least half of their time into the project. They’ll also be responsible for getting all the decisions made through the right channels in a reasonable period of time. You must have a leader like this to succeed.

4) Gain Consensus on the Definition Of “Finished”

Everybody on-board needs to agree on what constitutes being finished with any stage of implementation. For some, it will mean that by the end of each and every iteration, the production-ready software will be available. This is not always possible, so get out ahead of a potential problem and gain consensus.

5) Build an Exceptional Cross-Functional Team

Cross-functionality is what separates the ineffective agile teams from the high-performance ones. Team members have to be proficient in performing any and all necessary tasks so that they’ll be able to always deliver what the customers need.

Team building requires that you identify the right parties and that you shape them into a functional team by making sure that they share your own true goal of always delivering massive value to product owners.

6) Make the Proper Investment in the Tools That Support Agile

The beginning stages of any agile project will involve you investing in the of the robust frameworks, infrastructure, and process automation tools that fully support agility. This includes a wide range of solutions like continuous build servers, automation testing, video conferencing, interactive chat, and software frameworks. Don’t scrimp on other important details like the solution architecture, either.

7) Retrospectives Need to Be a Main Priority

Inspection and adapting are the keys to agile. Organisations using this methodology use a vehicle called “retrospectives” to ensure these tasks are being performed correctly. A proper retrospective should embrace the qualities of self-improvement and transparency. Any actions that are a result of the retrospective must be given the highest priority. This is especially true of estimations, which are crucial to achieving the kind of team velocity that keeps projects on track.

8) Start the Project with a Solution Architecture

Even though documentation is not always the most glamorous part of any project, you’ll be well served to make sure you understand that documentation is still important to a successful project. Using a solution architecture pays off because it serves a blueprint for the final project that will be delivered by the team. Team members need this document so they understand what will happen if they make changes. Members who are added to the project at later days will use the documentation as a reference point so they can be brought up to speed.

9) Embrace the Fact That Change Is Coming and Plan for It

You can’t make a change without a cost in agile. Change is something you always have to embrace philosophically, but be aware of the costs and the impacts to the project. When you are doing the estimation process, factor in potential changes when applicable.

10) You and Your External Partners Should Have an Agile Relationship

Agile is not always the best fit for traditional vendors. They prefer contracts that use fixed prices and fixed outcomes. When you switch to agile you’ll need to make a point out of understanding the ramifications the changes will have with your vendors. You and they may have to make some changes to keep the relationship running smooth.

Try to build a transparent relationship with all of your external vendors. Risk Reward contracts that employ clearly defined KPIs work amazingly well for agile organisations.

November 13, 2015July 1, 2022

The Good, the Bad and the Ugly of Agile Methodologies

The “agile” buzzword has really taken hold among a myriad organisations worldwide. That result is not particularly surprising. Who wouldn’t love to employ light and fast tactics that allow them to respond to rapidly changing challenges? Despite all the optimism about agile methods, the bigger question is how well companies are actually doing when it comes to employing these methodologies in the real world. Without understanding what the core objectives of embracing agile methods are, it’s not going to be easy to gain results.

Agile methodology is employed in order to reduce the time, risk, and cost that is associated with a project. However, these massive benefits are not going to materialise out of thin air. They are the result of the dedicated work of a team who is well versed in implementing the methodology.

To become “agile” will require organisations to take a quantum leap in their culture. They will have to embrace the entire philosophy behind these methods or no real change will take place. Truly agile companies are the ones that have gone through a transformative process in order to implement brand new processes that say goodbye to the past. This takes a lot of work and effort and not all organisations are willing or able to do this.

Ugly Agile Implementations

Project teams that are solely focused on results and who don’t do their homework end up with very ugly agile implementations. These teams are so excited about agile as a concept that they convert everyone in their organisation into adopting the methods. The problem is, they do not spend the requisite time getting everyone on board with exactly what needs to be done.

Because of this oversight, the projects are plagued with poor communications and engagement. The project team and others in the organisation are each working on their own tasks with no thought to how the pieces fit together in the “big picture.” This is a major problem because agile methods really only shine when the whole organisation works as one well-oiled unit. In this scenario, major issues at the core of the project are neglected and the entire project goes off the rails. This leaves a bad taste in the mouths of managers, who are no longer excited about agile methods.

Really ugly agile implementations have the wrong focus. Because of this myopia, the true benefits of agile employment are never realised. Before long, things, unfortunately, go back to “normal.”

Bad Agile Implementations

Some businesses completely miss the boat when it comes to agile deployment. They’re interested in receiving the benefits of reduced costs, faster time to market, and cutting “red tape.” Despite this knowledge, they’re not truly committed to the all of the values that are espoused by the Agile Manifesto. Without this commitment, they cannot possibly hope to fully embrace a functional implementation.

Organisations like to invest in education and communications, but they ignore important concepts like utilising the tools that help them truly embrace agility. They even form teams that understand cross-functionality, but without empowerment they are unable to make vital decisions.

Lastly, organisations that do poor agile implementations perform project reviews regularly enough, but the input from the meetings is never acted on by anyone. The key issues that are preventing proper implementation are never properly addressed and the project fails on its promise. Organisation members swear off the agile methods forever at this point.

Good Agile Implementations

When business personnel and IT staff work together, good implementations of agile are the result. These units work together so that a project delivery methodology is presented to the organisation that meets its needs. They also spend the time to create the cultural changes needed to ensure the methods are successful.

In organisations like this, team members, business end users, along with senior management and key stakeholders received a continuous education that empowers them all. Cross-functional teams that excel are the results. These organisations also invest in the techniques and tools that fully support agile. That includes test driven development, continuous builds, new standards, and more. With these in place, a platform that ensures long-term success will be installed.

Particularly telling, these businesses conduct regular project reviews which they conceptualise as opportunities to improve instead of something that simply has to be done. When change is needed, they embrace it and plan for it. When it arrives, they are ready and the organisation continues to excel. A sign of a good agile implementation is when the organisation is commits to making long-term changes that will benefit the methodology in the long run.

It doesn’t pay to underestimate just how difficult implementing good agile really is. Since major internal changes to how project delivery is done need to be embraced, the road ends up being a challenging one. Traditional managers will be challenged because empowered teams now have more input than ever before.

Once a good agile implementation is in place, the benefits are obvious and plentiful. An energised, cross-functional community of empowering people who are all focused on common goals get more done than ever before. Good implementation put platforms into use that improve project delivery because they allow for test-driven development, continuous integration, standards implementation, and best practice design applications.

November 3, 2015July 1, 2022

Top 10 Project Management Myths Debunked

Since the dawn of time, mankind has used myths to make sense of the uncertainty that surrounds us. In the early 1990s a lot of people believed that project management was the best kept secret in business. However, because project management was not seen as a prevailing profession at that time, it suffered from a lack of awareness which was in a sense, a double edged sword. Those who were knowledgeable in the practice of project management became extreamly valuable to organisations and pioneers for the profession.

These early adopters were able to convince organisations that project management practitioners were needed. Myths around project management began to form in the business community and as the role of the project manager was unclear, questions were raised as to what project management was and what it could offer organisations.

The definition of the word myth is a “widely held, but false belief or idea.” Here, we’re going to examine 10 of the most pervasive PM myths that have emerged.

Myth #1 – Contingency pool is redundant

This is one of the most ‘mythical’ myths that has plagued the industry for a long time. Coupled with the tendency to presume that ‘real work’ is tantamount to implementation or building something concrete and you have the perfect recipe for project disaster. The thought pattern behind this approach typically originates from budget constraints and/or having unrealistic expectations. As we all know, or should know, the unexpected happens quite regularly. An effective contingency plan is important as it aims to protect that which has value (e.g., data), prevent or minimise disruption (e.g., product lifecycle), and provide post-event feedback for analysis (e.g., how did we fare? did we allocate funds correctly?).

Myth #2 – Project Management software is too expensive

If your idea of project management software involves purchasing servers, and purchasing a software application from a major vendor for a small practice with 10 practitioners then, yes, it is too expensive. If, however, you have gone cloud and elected to use a powerful web-based project management solution (such as Smartsheet), then you are likely to save thousands of pounds while reaping the benefits of a pay-as-you-go price structure. The present, and future, lie in cloud solutions that provide equal, or superior, functionality at a fraction of the cost.

Myth #3 – Project Management methodologies will slow us down

Project managers have a reputation of using process-intensive methodologies that favour ideology over pragmatism. In some instances this may, indeed, be the case when there is a mismatch between a specific project management approach and the organisation’s acutall needs (e.g., a process-driven method, such as PRINCE2, may not be appropriate for a slightly chaotic environment that favours an adaptive approach, such as Scrum). So, in sum, put down the paint roller (“Project Management isn’t for us!”) and take out your fine-bristled brush (“The Critical-Chain method may not be our cup of tea, but Agile on the other hand”¦”).

Myth #4 – Facts and figures are more important than feelings and perceptions

While facts are very important, projects are often derailed and sabotaged because of false perceptions. The PM must pay attention to both fact and fiction to navigate through turbulent organisational change.

Myth #5 – Project managers need to be detail oriented and not strategic in nature

While it is of the utmost importance for the project manager to understand how to read the details of the project, they must also understand how the project supports organisational objectives. Having a strategic perspective adds great value to the skill-set of the project manager.

Myth #6 Rely on the experts in everything that you do

It is true, we do need to rely on the experts but our trust can not be a blind faith. The job of the project managers in this area is twofold. First we must extract information and second we must verify that the information is accurate. A good example of this is asking a planner to provide an estimate on the effort required to perform a task. In some instances team members forget to include tasks which ultimately results in a faulty estimate.

Myth #7 All the battles have to be fought and won so that we can succeed

Project managers sometimes make the assumption that they need to stand firm to get the job done, however, coming to compromise on a particular issue is often a better course of action in order to win the war.

Myth #8 Project Managers can wear multiple hats

Wearing different hats can be extremely confusing. This is especially true if the project manager is asked to be a business analyst or technical expert on top of serving in their PM role. They end up doing both roles with mediocrity. When we “wear two hats” we essentially tell ourselves that both hats fit on one head at the same time. However, what happens if the demands of two roles conflict and what assurances do we have that we’re managing the inherent conflict of multiple roles and the risks the roles introduce? Sadly, multiple roles become more common as we move up the management hierarchy in an organisation, and that’s exactly where potential conflicts of interest can do the most harm.

Myth #9 Once the risk register is created, it’s full speed ahead

Risk management provides a forward-looking radar. We can use it to scan the uncertain future to reveal things that could affect us, giving us sufficient time to prepare in advance. We can develop contingency plans even for so-called uncontrollable risks, and be ready to deal with likely threats or significant opportunities. Too often, it’s not until a catastrophic event occurs and significantly impacts project progress that ongoing risk reviews are conducted.

Myth #10 Project managers can not be effective in their role unless they have specific technical expertise in the given field that the project falls within

You don’t need to be an engineer to manage a construction project or a IT technician to manage a software development project. All you need is a fundamental understanding with strong PM skills to manage the team. Experience in the field helps but does not guarantee success.

Project management is challenging enough without the myths. The profession has come a long way since the 1990s and some of these myths are fading. However, we still see remnants of them in one form or another. Great projects cut through false assumptions and confusion, allowing their teams to make smart decisions based on reality.

These are just 10 project management myths, what are yours?