Articles about Agile Methodologies
We have seen how Project Management as a profession has matured over the past few decades. There were numerous shifts concerning tools, approaches and training, to emphasis on new skills and pursuing certifications.
Enjoy the summary in the Then & Now Infographic brought to you by Wrike project task management software
By Ashley Lipman
With the rise in Agile adoption, the need for a streamlined process around the software development life cycle, through development and testing to production is paramount. The capabilities that make up DevOps are provided by people, defined practices and automation tools, according to the DevOps for Dummies. (Source: DevOps for Dummies by Sanjeev Sharma, Bernie Coyne)
While shifting to a DevOps approach is ideal for agile team to deliver value to customer faster, it can cause problems within a project development team. In fact, it’s been known to cause a few problems during the production implementation.
Here are some of the challenges faced by DevOps teams today.
Not having clearly defined roles and permissions for a DevOps teams can cause many problems.
When it comes down to it, developers and operations teams have different roles that sometimes overlap. It’s important to address these overlaps so that everyone knows not only what they’re responsible for, but what they aren’t permitted to do. For example, developers shouldn’t be able to access the same logs as sysadmins (source: https://papertrailapp.com/log-management).
Roles will allow DevOps teams to utilize applications that will encourage access rights management that promote effectiveness and compliance.
While starting to implement DevOps, it’s important to take a gradual, strategic approach. Rather than trying to transfer all new projects to the new management system, choosing a few projects and analyzing the benefits and challenges is key. From there, refining the implementation process and expanding will help make DevOps successful.
That being said, not all projects are meant for a DevOps approach. Many businesses are faced with challenges when it comes to change management. While one of those challenges is letting go of the old way, another is often identifying when the old approach works better for a specific project.
One of the main benefits of DevOps is the ability to finish projects quicker through a continuous feedback loop. However, quicker isn’t always better, especially during the early days. When aiming to move more efficiently, it’s critical that DevOps teams don’t neglect the testing process. Quality assurance testing to ensure that everything is bug-free is one of the most important steps in development, and the DevOps approach doesn’t always put this task in the limelight.
When releasing an app with bugs, it can cause a bad user experience. This can cause a blame game with the development and operations teams, creating a negative team dynamic that will impact future projects.
Focusing too much on the tools and not enough on the team dynamic is a unique challenge that many organizations face when switching to a DevOps culture. However, not putting enough attention into the infrastructure and tools can also be detrimental.
Using legacy infrastructure while trying to modernize standard operating procedures can be a significant limiting factor, even if the current infrastructure has been useful for years. The businesses that have the most success with DevOps are those that switch to a micro-services approach, implementing automation and innovating their old applications.
Of course, making these changes can be a monumental task, and can often lead to a “chicken or the egg” conundrum when trying to determine which practices versus which infrastructure should be changed first. Managing all of these changes without getting distracted by the wide array of tools meant to assist with DevOps can be time-consuming and costly.
Creating a successful DevOps culture isn’t an overnight process. It can take months of creating a culture of positive communication and cohesion between teams, and even longer to take a sustainable approach to scaling.
However, by focusing on the team itself, having the right foundation in place, and testing rigorously, DevOps can change the face of a business for the better.
By Louise Worsley
Appropriate planning of a project is the hallmark of a professional project manager—good planning is what sets apart great projects from failed initiatives. It is what ensures that the executive actions undertaken remain connected to the goals and outcomes expected by the stakeholders. A project plan is a framework for decision making throughout the life of the project. It is hardly surprising then that the significance of planning in projects is much greater than in any other management discipline.
Today if you ask a project manager what the most important skill they require for their job is, they are likely to refer to areas such as stakeholder management, communications, leadership, or behavioral competencies. Is this because it is assumed that planning is obviously important and does not need to be mentioned or is it that project managers believe that with the right leadership style, communications and engagement they don’t need planning? Do approaches such as Agile, which expound people over process, deliberately or inadvertently promote the obsolescence of planning?
After more than 70 years of experience in project management, and working with hundreds of professional, high-performance project managers, we know planning in projects is essential, but have also found the planning discipline to be both underused and misunderstood. Three factors we believe are responsible:
In our research into what makes project managers successful, planning, along with monitoring and control, are the two areas where high-performance project managers spend most of their time. What is also clear from the findings is that the most distinctive characteristic is their ability to use their experience and know-how to adapt their planning approach to meet the specific challenges of the project they were managing.
There is no single approach to planning a project, but neither is project planning a free-for-all. One consistent finding is that the context— the environment within which planning takes place—determines the approach that is most appropriate to use; which techniques and tools are most suitable; and what factors to consider.
Louise Worsley, with her husband, Christopher Worsley, are the authors of Adaptive Project Planning, published in February 2019. This book prepares you for many of the common project planning situations you will meet. It addresses how planning and planning decisions alter, depending on the constraint hierarchy: how resource-constrained planning differs from end-date schedule planning, what is different between cost-constrained plans and time-boxing. It also discusses the challenges of integrating different product development life cycles, for example, Agile and waterfall, into a coherent and appropriate plan.
Readers of Virtual Project Consulting who buy the book now, will receive a discount of 15% – use buying code WOR2019. Click on the image!
By Brian Thomas
Agile is taking the project management world by storm, and for good reason. Traditional methods of project management that rely on rigid timelines tend to break down when things change. On the other hand you have the Agile project management system that’s actually designed to handle change. With Agile, teams can easily adjust to any issues, setbacks, or new priorities that might arise throughout the process. Change happens all the time, even within Agile itself, so it’s best to make sure your team is prepared for it.
Using the Agile framework and being prepared for when things go awry is great, but you’re going to need to leverage technology to keep everyone on your team in the loop. Check out the top tech tools to keep your agile project on the right track!
Trello is a good option for getting your whole Agile team on the same page. One of the great things about Agile is that it encourages face-to-face team engagement, which often leads to the use of physical whiteboards. Since Trello functions similar to a classic whiteboard, it makes keeping your physical documentation up with your project management tool simple and effective. Once in Trello, you’re able to set up boards for you and your team. Within each board you can create lists, and then nest individual tasks underneath those lists. The flexibility Trello provides for users makes it perfect for Agile.
If you’re looking for a project management solution that’s simple and to-the-point, then check out Asana. Asana is an easy-to-use task management system to track progress on all of your team’s projects. Similar to Trello, you can set up task sections for your backlog, current sprint, complete, and any other grouping you might need.
Instead of centering your Agile team around the tasks that need to be done, Proggio puts the focus on the actual team members themselves. Proggio makes it easy to visualize workflows to see what tasks need to be done, when they need to be done, and most importantly, who’s responsible for doing them.
Proggio’s ability to visualize how the team is functioning as a whole helps the team members understand why the work they’re doing is important and help the team build momentum to operate efficiently.
ProofHub is a comprehensive project management and collaboration tool designed to streamline workflows and improve team productivity. It offers a wide range of features, including task management, document sharing, team collaboration, time tracking, and more. It has been trusted by thousands of businesses and teams worldwide.
Binfire is another Agile project management software tool that allows teams to seamlessly collaborate on projects and tasks in a simple and concise manner. Much like Trello and Poggio, within Binfire you and your team can use visualization tools such as a digital whiteboard to map out your systems and processes. However, with Binfire you can also utilize additional types of charts, markup PDFs, and chat on your team message board among other features.
Last but not least is Drag. Drag is a free chrome extension that lets you turn your gmail inbox into projects and their accompanying lists of tasks. If your team works within a single email account, such as the company’s “info@company.com” email, it’s perfect for organizing your gmail inbox into its own Agile system. Or if you’re just a big Agile fan and you want to turn your own personal inbox into an Agile workspace, you can do that as well!
There are many more great tools out there to help Agile teams maximize the efficiency of their workflows.
Find a great resource of curated and reviewed project management tools that is best to use for different industries such as creative, design, marketing, developers and other areas! Click here.
*****************************************************************
About the Author:
Brian Thomas is from Enlightened Digital, a digital magazine dedicated to the top tech and business news, updates and analyses from around the web – your guide to everything at the cutting edge of technology.
It’s only in recent years that I started working on Agile projects following the Scrum approach. And what a journey it has been so far! Challenging that traditional way of working mindset of being a PMP (Project Management Professional) for 14 years working mostly on ‘waterfall’ type projects.
You find yourself facing common struggles while going through the motions of changing your mindset which really is essential for successfully adoption an agile approach.
Companies who provide consultation and training around Agile, realise that teams are faced with many challenges when making the transition to Agile. At Knowledge Train they have published an e-book with stories from Industry experts who shared about their challenges with Agile and the solutions they use to overcome it.
Below is an Infographic with some of the most common challenges!
Please click on the Infographic to reach the article where you may download the e-book: “The Challenges with Agile”.
Watch this video to learn about 8 key elements of the Scrum Master role.
When you fulfill the important role of Scrum Master on a Scrum Agile team, here are valuable aspects to focus on.
For more details on the Scrum Master role to help you gain a better understanding, read the White Paper:
Whether you’re a project manager working in a traditional Project Management environment following a certain methodology to get your projects done, or whether you’re in an Agile approach organisation where both Agile approaches (like Scrum) and traditional approaches are followed or a hybrid of both, this article will be of interest to you. It was written by a fellow Project Management Practitioner and blogger, Kevin Lonergan, who has used Agile and non-Agile approaches for managing projects for two decades and is a career long project management professional.
The article discusses the difference between Agile and project management and why, when using Agile, there are times when they are both required. It also shows why Agile is not a PM framework itself and highlights many of the specific reasons why this is. It discusses the difference between product development methods (e.g. Agile based methods) and project management, and shows examples of why the two are not the same.
The article takes a frank view of the real world of projects in business and what is missing in some implementations of Agile.
Read the full article here:
https://www.pmis-consulting.com/why-agile-will-never-be-a-project-management-framework/
Please let me know in the comments what you think of it.
By Simon Buehring
Scrum is an agile development framework used for managing product development. Like all other agile frameworks, Scrum boasts flexibility, team collaboration and iterative delivery.
This visual guide was developed to help you understand how the Scrum Methodology works. You can even download an A0 size version of the poster and print it to display in your office!
1) Select Scrum TeamOne of the most difficult parts when creating a project is figuring out roles and responsibilities. Begin by identifying the roles people will take for the project.
The Product Owner should be someone with authority, availability and vision. They represent the customer and continuously communicate the priorities and vision to the team.
The Scrum Master acts as a facilitator between the Product Owner and the Development Team. The Scrum Master will also work to remove impediments that may inhibit the Development Team reaching the sprint goal. The person does not, however, provide day-to-day directions or give instructions to the Development Team.
The Development Team are self-organized and responsible for developing the product.
Do:
Don’t:
Top Tip:
Once the roles have been identified, it’s time to start planning the sprint. The whole team decide on a sprint length together, overseen by the Scrum Master. Sprints are typically 2-4 weekly cycles.
The Product Owner creates a product backlog which is essentially a ‘prioritized wish list’. The backlog is owned by the Product Owner, but everyone can add to it. The product backlog contains a list of user stories.
User stories serve as a guide for the team to show why they are working on something. They speak from the end user perspective and can look something like this:
| As a | I want | so that |
| Music lover | uninterrupted music streaming from my device | it doesn’t use up storage space while letting me play music on the go |
| Music streaming app user | to receive recommendations based upon my current playlists | I can hear new bands that are suited to my taste |
The Product Owner presents the highest priority user stories from the product backlog to the Development Team.
The Development Team decide on what they are able complete for the sprint and break user stories into tasks, estimating the effort and transferring them to a sprint backlog.
It is essential that the Scrum Master and Product Owner provide a set of acceptance criteria for each user story. Acceptance criteria is what determines whether the user story is complete. It can also be referred to as the “definition of done”.
The table below shows two user stories with two sets of acceptance criteria.
| As a | I want | So that | Acceptance criteria |
| Music lover | A small-sized streaming app with no adverts | it doesn’t use up storage space and interrupt my listening experience | 1. App allows user to stream music without downloading 2. App size is 60MB or under 3. App offers premium subscription with no ads |
| Music streaming app user | to receive recommendations based upon my current playlists | I can hear new bands that are suited to my taste | 1. Radio feature created based upon user’s playlists 2. Daily “Have you heard..” notification to be sent to users |
Do:
Don’t:
Top Tip:
To make sure that everyone is in sync, the team must meet every day to discuss what they worked on the previous day, what they will work on today and identify any impediments. To make sure that time is used efficiently, the meeting should be time-boxed into a maximum of 15 minutes. The Scrum Master oversees the meetings and makes sure that the team focuses on the subject at hand.
Do:
Don’t:
Top Tip:
By the end of each sprint, the Development Team should deliver a potentially shippable product increment. In other words, the product increment should be in a useable condition. No incomplete work should be presented during a sprint review.
During a sprint review, the team present what they have accomplished during the sprint. They demonstrate the functionality of the product increment to the Product Owner and customer. The purpose of the sprint review is to get feedback from everyone on the product increment. After the feedback is shared, the next set of product backlog items can be discussed.
Do:
Don’t:
Top Tip:
During a sprint retrospective, the team evaluate the whole sprint. The two main questions that are asked are “what went well?” and “what can be improved in the next sprint?”
The product increment is the output of all the product backlog items completed during the sprint (plus any previous sprints). It must be fully functional, in a useable condition and meet the allocated acceptance criteria or definition of done. The Product Owner decides whether to release the product increment.
During an interim delivery, the product increment is tested by the customer. If the product is incomplete, the Development Team return to the product backlog to prepare for another sprint. This cycle repeats until all user stories are completed to the Product Owner’s satisfaction.
Do:
Don’t:
Top Tip:
Completing a project takes several sprints. Once all the user stories are completed to the Product Owner’s satisfaction, the product is ready for final delivery to the customer.
*********************************************************************
About the Author:
Simon Buehring is the Founder and Managing Director of Knowledge Train.
By Joel Roberts
Even though the Agile method is now being increasingly adopted by organizations worldwide, especially for software development, too many organizations still cling to Waterfall. The existing processes are probably influencing the decision of what methodology is used.
Your organization’s current processes are likely to determine the way you run your project, regardless of its nature. But, this shouldn’t be the case. Project managers are more than able to assist their organizations and suggest effective ways of implementing projects while reducing risks at the same time.
For this, you need to have a deeper understanding of how each project management methodology may impact the project and its success. Choosing the right methodology can be key to successful completion of a project. So, if your organization still uses the waterfall methodology, read on and see for yourself why this needs to change.
As you know, the Waterfall method is a sequential approach, separating a project into different phases, where one phase has to be completed before starting the next one.
So here are the 4 crucial flaws caused by this:
The Waterfall method in its core means following a predetermined set of steps, as the methodology, in its traditional form, leaves almost no room for unexpected changes or revisions. You have to be clear with all the development requirements beforehand and just keep your team always moving forward.
A probable and highly undesirable scenario is that your team will carefully follow the steps nearly to the end of the project but, they may face an unforeseen obstruction that requires a change in scope or goals. Since the used methodology doesn’t welcome change, proceeding with the initial plan won’t be easy. As you’ll have already put a considerable amount of work into a project, under very specific and fixed assumptions, an unexpected change to any parameter of the project may render much of the finished work useless.
This may have severe consequences and even throw off the entire timeline. Another aspect of Waterfall that reduces flexibility is that Waterfall projects are highly integrated and not an object-oriented approach.
When using this method, you must produce a detailed and thorough requirement definition in one of the earliest phases of the project. But, in such an early phase of the project, trying to define the requirements is often very difficult.
Therefore, many of the requirements are subject to change throughout the project. Specifying requirements in advance means that a lot of the requirements are based on assumptions. You may come across many difficulties to validate those assumptions since the first builds are not available until late in the development phase.
Even the client has to outline all their preferences upfront, without seeing a working version. Once the first builds are available, it’s often too late to change requirements without substantial delays of the project. Also, when planning everything up front, very often you can overlook certain changes due to business plans or market influences. Since change is unwelcome and difficult to carry out, any new developments or changes of requirements which may occur after the initial agreement could raise serious concerns.
Testing is a very important phase of a project as the results have an impact on all the work that has been done. The best practice would be to integrate testing as a fundamental and continual process throughout development. This has been the case with more recent SDLC models, whereas the waterfall model largely differs, leaving the testing until quite late into the life cycle.
This means quality and security issues or integration problems with existing products are typically discovered quite late in the process. Fixing such issues requires a lot of effort. What’s worse, sometimes testing may be short-changed in order to stay on schedule, and that means that bugs will be discovered by the customer only after the delivery of the product.
In turn, this makes fixing the code expensive and time-consuming. It has been shown that a bug identified at a later stage can cost up to 60 percent more to get fixed, as compared to its cost when identified at an earlier stage.
Another issue related to the testing is the possible appearance of careless coding practices. Testing teams often have less time to complete test execution and since more time is spent during the initial stages for detailed documentation, not enough attention is paid to testing.
At times when communication seems to be one of the crucial factors that can impact project’s success, you cannot afford to leave the client or stakeholders out. In the Waterfall method a lot of time is spent with the client at the outset, with an attempt to document all the perceived requirements.
After this has been done, the implementation team usually take over and the client has no say until the project is nearly done. However, the feedback that arrives late into the development cycle can present a significant issue.
Due to the strict sequential process enforced by the waterfall model, an unforeseen requirement or request for a change, although not impossible to be done, will be both costly and time-consuming for everyone involved in the project. So, this method is definitely not suitable for projects with moderate to high risk of change of requirements.
If you are still not completely convinced with these reasons, add the high amounts of risk and uncertainty, longer delivery time, and other challenges that project schedulers might face to the list.
Considering the shortcomings of the Waterfall approach, which method do you prefer? Which factors made you decide?
Please provide some feedback in the comments section.
**************************************************************
About the Author:
Joel Roberts is a Project Management Consultant and an established author with more than 12 years of experience in working for PrimaveraReader – Primavera P6 companion tool for viewing and analyzing project plans by the project team.
She is passionate about Mind Mapping and innovation management and her articles have been featured in more than a hundred project management and business websites.
By Derek Smith
In today’s digital and disruptive world, executives and organizations are faced with fierce competitive challenges that require them to continuously adapt, or else face the consequences and the stark possibility of not being around for much longer. The same goes for project managers who need to keep abreast with what is happening with Agile methods and philosophies in Project Management in order to keep themselves relevant and employable.
Flexible Agile and Lean practices, such as Scrum and Kanban which were once the sole domain of software developers, are uniquely positioned to create business success, and are making significant inroads outside of IT and finding acceptance and support by C Level executives. Organizations need to quickly sense and adapt to external and internal changes to deliver results productively and cost-effectively, without losing sight of the fact that governance is still required.
The quest for success also starts with the right approach to support project delivery, and specific project characteristics and organizational needs should form the basis of selecting the correct approach.
With everyone hopping on the bandwagon to capitalize on training and adoption, combined with so many choices when it comes to approaches, it can be daunting to try and keep abreast of how these practices are evolving, and how and what to choose. PMI have a series of reports which have been geared towards thought leadership, and it is pertinent to note that six reports deal with achieving greater agility.
The reports cover topics such as focusing on the customer, frequent feedback, choosing the right approach and transforming the organization by focusing on people and monitoring progress. Evolving the collaboration between lines of business, changing the culture and assessing the need for cross-functional support are other key aspects to consider when seeking to achieve greater organizational agility.
From a career standpoint, project managers need to keep themselves relevant to be employable and earn a decent wage. PMI’s Pulse of the Profession® research has indicated that stakeholders are pushing to adopt agile practices. Organizations that are agile and responsive to market dynamics, complete more of their projects successfully than those that are not — 75 percent versus 56 percent, according to the research.
It is for this reason that they have included information on agile practices, alongside traditional approaches in the PMBOK® Guide – Sixth Edition, and partnered with Agile Alliance® to create the new Agile Practice Guide. The PMI-ACP® is currently the fastest growing PMI certification, and spans many approaches to agile such as Scrum, Kanban, Lean, extreme programming (XP) and test-driven development (TDD.).
Achieving greater agility
Agile certifications
****************************************************************************************
About the Author: Derek Smith has over 24 years of experience in the technology and ICT industry. He has been a CIO for 2 listed companies, and has also managed some of the top outsource operations for 2 of South Africa’s leading service providers. He is currently a Projects Portfolio Manager, Mentor and Coach, and is an advocate and evangelist for Agile philosophies and methods.
By KnowledgeHut
While it may sound simple, in reality, the tasks of an Agile Scrum Master cover a very broad spectrum. When managing and implementing the project is the need of the hour, the Agile Scrum Master must be equipped with good training and certain tools in their toolbox, so that they can accomplish and interact with their stakeholders, as and when required.
With the ongoing demand of Agile training, there are so many institutes on the rise that are offering courses like Certified Scrum Master Training and giving you a professional approach. The courses are designed in various stages and based on your skills, expertise, and levels; one can choose the desired course.
The biggest advantage is that the courses are available online, making it convenient for you to do from any part of the world. You only need to register for the course and you can study even in the comfort of your house or while traveling.
On completion of the course, you will be awarded a certificate. With this certificate in hand, you are eligible to apply for a position in any organizations. In the initial level of the course program, agile management training will help you to grow the following skills.
Without the use of certain tools, the work of an Agile manager can be really tough. Keeping this in mind, there are so many tools available, that have been designed to provide all the essential features.
Some of the recommended tools have been mentioned below, which can be considered.
The task of an Agile Manager is going to be much simpler if you have done training to equip you with the right skills and if you have supporting tools in the workplace.
************************************************************************
KnowledgeHut offers over 120+ professional certification courses across industries to helps professionals get an competitive edge and boost productivity. KnowledgeHut is an industry-leading knowledge training company for individuals and corporate offices, operating across 70 countries and 6 continents.
Click here for what is on offer for project management training.
This story from Lance Hamel, is about a complex Customer-centric strategic project to improve customer experience in the Retail Industry that took 7 months to complete. The complexity was due to having to implement an unknown cloud-based solution using an agile approach in a traditional waterfall environment, with an unknown vendor. The systems integrator promised technical skills some of which they didn’t have, and subsequently had to be outsourced. That delay caused increased pressure towards the end of the project.
After less successful prior attempts, the team was mobilised quickly and was able to deliver a minimum viable product (MVP) after 6 months. This was an early win for the business and it took about one third of the time it normally takes to implement a new solution.
The Business had an active and involved project sponsor who was also the product owner. Through-out the life-cycle of project, following an Agile approach, the project team was aligned on a daily basis. The Sponsor had a briefing 2-3 times a week, when she did regular prioritisation with her team; therefore there was a close alignment between business and the project team.
The vendor was leading the agile process. They had a very transparent way of working between IT and Business,. The right stakeholders were involved with sprint planning, backlog grooming, reviews and briefings. They also attended sprint reviews/retrospectives in a continuous improvement process.
There was a complete shift in the way they managed the project. Instead of …..
Read more ….. for many lessons learned and key take-aways for future projects.