Implementing PLM 4.0: Getting Started With Scrum Speed
Not so long ago, it was said that software was eating the world! But while the top 5 market-cap firms are essentially software firms, leveraging the network effect of Platformization, it’s not entirely true. Because while the top firms of Amazon, Google, Microsoft, Apple & Facebook continue to prosper, there’s plenty of other software firms that have gone the other way.
To me, it’s more about adapting, innovating and at speed — it’s a focus on delivering value for customers, working in small teams in short cycles and networked organizational arrangements, rather than top-down bureaucracy and silos.
An unstoppable 4IR is under way, affecting almost everyone. Agile organizations are connecting everyone and everything, everywhere, all the time. They are capable of delivering instant, personalized, frictionless value on a large scale.
Speed Is Everything
It feels like not a day passes without me reminding my team that “speed is everything”.
Speed of action, speed of innovation, leads to failures and losses, but I love them both, because it means we will find the best way to do things, before anyone else!
With the speed at which the world of business is moving, keeping up is a constant task that never gets any easier. In a world where everything is moving so rapidly, simply being fast isn’t enough; you have to be faster than anyone and everyone. Accelerate until you’re at the front and move fast to stay there.
We live in an age of near-instant gratification, where consumers are not-so-patiently awaiting the next big thing. People simply aren’t satisfied with the status quo; they want something more and they want it now. Companies must work quickly to satiate their appetites because audiences will have no qualms about moving to another product or service.
Once you learn to move quickly and maintain speed, a culture of speed naturally forms, where standards for speed are just as high.. With everyone and everything moving faster, innovation and efficiency go through the roof, blowing back your competition and blowing away your customers. No company in any industry can expect to get ahead with a slow culture; by design, entrepreneurship is all about moving forward and pushing innovation forward.
Start Innovating, Start Collaborating
Without a collaborative approach to design, how can we compete in the 4IR? Without new and disruptive products and services, how can we survive and thrive?
Imagine using technology to link in “outsiders” such as suppliers and customers into your development projects and coming up with better ideas more quickly and cheaply than you’re doing today?
Imagine a technology company orchestrating the design of a new vehicle through an open network of interested customers, software engineers and suppliers, all working internationally with one another. It’s the model of like-minded parties. It’s starting to happen all over the world.
Most industries are climbing aboard the collaborative approach to new product innovation
Digital innovation and digital organizations are co-dependent and intertwined.
Using Scrum for an Agile PLM implementation
It is generally a challenge that IT projects often take far too long, becoming too costly and never ending up with the exact solutions that customers are looking for. Furthermore, it is frequently difficult for vendors and systems integrators to uncover exactly what solutions the customers want and therefore to spend a lot of time digging into extensive requirements, specifications and contracts.
As a result, we have looked over the years for methods that could help deliver software solutions that customers could start using earlier, and in a way that more accurately meets their needs. Over the last few months I have spoken with various large enterprises that have experienced the Agile methodology to deliver results.
Customers wishing to implement PLM systems will find there is so much happening in the product innovation, asset lifecycle space that there is so much they need to have knowledge of, that they often have to think faster, react quicker before what they started to achieve needs to change. It can be difficult for customers to visualize how the end-solutions will turn out and therefore it is difficult for them to create a complete specification that matches what they really want.
Traditional projects have been governed by a contract and a specification showing what to deliver. The Agile methodology today is based on a small, self-directed team or series of teams working closely with customers and progressing by solving one task at a time within given deadlines.
Let’s Get Started
These self-directed teams are called the “Scrum team”, the team is led by a “Scrum Master” and every time the team works together to solve different tasks, it’s called a “Sprint”.
It starts by gathering the minimum requirements for the customer to be able to start using the system. These minimum requirements are the foundation for the delivered project. As a result, customers can start using the systems quickly, and therefore the benefits for the business can be realized very early.
The scrum team’s work takes place in the form of short sprints where it is allowed to fail along the way. This enables the team to learn from their mistakes and quickly move forward. The advantage of these short sprints over 2–3 weeks, between the different sub-goals and deliveries, makes it easy to correct errors along the way and adjust the course. That is why this project methodology is called Agile, being a seamless way to work.
Starting with the bare bones and outline of the project and asking the customer which tasks are the most important and solving these first, speed becomes the backbone. As the project progresses, feedback is sought to ensure the team(s) are heading in the right direction.
Following Protocol
The Scrum teams do have structure and processes and is a way to implement Agile. Scrum is deliberately lightweight, simple and fast, but it is difficult to master. It is intended to provide a framework for cross-functional teams to solve complex problems, through a series of meetings (ceremonies).
They are not just meetings for the sake of having meetings. These ceremonies provide the framework for teams to get work done in a structured manner, helping to set expectations, empowering the team to collaborate effectively, and ultimately to drive results. If they’re not managed correctly however, they can overwhelm calendars and drown out the value they are intended to provide.
The four ceremonies are:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Now, conducting these meetings in isolation won’t automatically make your project team agile. They have to be a part of a larger, well understood and articulated process.
Sprint Planning
Sprint Planning is the scrum ceremony designed to ensure the team is prepared to get the right things done across every sprint. It happens at the beginning of a new sprint and is for the Product Owner (PO) and Development Team to meet and review the prioritized Product Backlog. Through a series of discussions, the team should create an agreed team sprint backlog that contains all items they are committing to complete at the end of the respective sprint (sprint goal). The PO is responsible for having the Product Backlog ready, including the acceptance criteria, requirements, and necessary details for the development team to accurately estimate the level of effort for review before the Sprint Planning.
Successful sprint planning relies on an experienced Scrum Master to guide the team through the nuances of success; taking the User Stories, often breaking them up into smaller tasks to ensure accountability, collaborating throughout and to consider everyone’s input and workloads, but at all times keeping the focus on the tasks in hand, not being sidetracked.
Daily Scrum
The Daily Scrum is the team’s chance to get together, define a plan for the day’s work, and identify any blockers. It provides a frequent opportunity for the team to get together, communicate individual progress towards the goal(s) and there to highlight any impediments for the team. The Scrum Master is responsible for clearing these roadblocks for the Development Team so they can focus on delivery.
It’s the job of the Scrum Master to maintain pace, holding the same time each day and giving everyone their time to speak, while maintaining focus and a light and fun tone. Of course, things can arise that demands greater time for discussion and it’s the Scrum Masters job to push team members to collaborate and self-manage outside of the meeting.
Sprint Review
The Sprint Review is the scrum ceremony where all work completed during the sprint can be presented to the stakeholders. This allows the stakeholders to see things as soon as practical for inspection and adaption as the functionality emerges. Most importantly, all of the work showcased during this time should be fully demonstrable and meet the definition of done. The team should feel empowered to show off the work they’ve been able to complete and should focus on the business value being delivered through product development.
In attendance should be the Scrum Master, the PO, development team and a blend of management, outside stakeholders, and “customers”. The Scrum Master will organize the meeting and ensure everything and everyone is set-up. During the meeting, actionable feedback is sought and should be added to new product backlogs. The Product Owner should be asking questions to the stakeholders, gathering feedback, and also providing answers to any that arise
Sprint Retrospective
The Sprint Retrospective is the final scrum ceremony that allows the team to look back on the work and identify items that could be improved. Ultimately, this ceremony should provide a blameless space for members of the team to provide their honest feedback and recommendations for improvements. It must drive change and for actions to be agreed for members of the scrum team to understand who is responsible for what.
Agile is all about constant improvement, and this ceremony is specifically designed to help the scrum team better. By focusing on continuous improvement through presented facts
Focus on continuous improvement and gather information that is based on facts, not just feelings. If a suggestion for improvement is brought up, ask other members of the scrum team if they all agree and if so, identify how that recommendation will be brought to life.
Keep generate meaningful insights from the conversation and if you sense there’s more to be said between the lines, encourage team members to go deeper.
The Future Of Scrum
The framework sound ideal to bring through rapid results, however many Agile projects have reported challenges.
From measuring success to transitioning from predominantly Waterfall based projects to clashing with corporate cultures of fear of mistakes to the move from output to adding customer value.
The standard command-and-control processes of a hierarchical bureaucracy that are still prevalent in large organizations today are behind the perceived poor performance in economy-wide innovation. Those processes are ill-suited to innovation. Managers recognize this but what often happens is that teams are deployed on an ad hoc basis when the organization see problems that the bureaucracy can’t solve. Once the teams have solved the specific problem at hand, the teams are disbanded. There is no specific capability created for systematic innovation and any that are created tend to be infected with control-minded bureaucratic mindsets.
The enterprise culture has to change for Agile and Scrum to truly embed itself in the future and to deliver the true promise of the 4IR.