The challenge of Nexus, Scaled Professional Scrum (SPS)

I am in a project running with scaled scrum using Nexus framework. Nexus means a relationship or connection between people, which is a unit of development in scaled scrum. Software development is complex, and it’s more challenging with multiple teams build on the same product with many dependencies during the integration. Other than more roles, artifacts and events, here are three main issues I found in day to day work:

  1. Nexus Sprint Planning with only one Product Owner

According to the scrum guide, there is only one single Product Owner who has the final say. After the nexus sprint planning, multiple teams run their individual sprint planning, then it becomes tricky logistically for Product Owner to join all of them. If the individual team’s sprint planning happens concurrently, then it is impossible for him/her to answer questions on domain knowledge and priority decisions at the same time. If the meetings are arranged asynchronously, then it would be quite time consuming for the Product Owner. Furthermore, some resources may be shared among different teams, such as the same Scrum Master, Senior architect and designer within the same product. Even worse, some organisation may assign a group of product owners to take the same role of maximising the value, which would leads to other problems in practice with nobody has the final say of the scaled product.

2. Visualising of the Product Backlog Refinement

New dependencies may emerge, which should be visualised and minimised. However, there are no great tools in the market existing yet to help easily visualise the dependency’s status, whether it is in progress or if it is resolved. JIRA and trello are lack of features for cross-team refinement board, and it could be frustrating to keep chasing up for status as well as finding the right person who has the technical skills to understand why it is an impediment. Due to the complexity, the scrum master may not have enough understanding of the full picture either on the details or the impacts to help manage the dependencies.

3. Nexus Sprint Review with drop of Velocity

There are integration related work to do, which could leads to a drop of velocity. However, which team should do the overlap work is a question, while different teams has a different estimation baseline and different agenda. Some integration work is time consuming, such as deployment of servers, setting up automated test and resolving git code merge conflicts. These are necessary but time consuming work, which could be benefits to both teams , while the values are not fully reflected in story points, but only lead to a drop of burn down velocity. Senior management would then cause a lot of troubles on addressing why the velocity decreases. Furthermore, even if each team completed their stories according to the Definition of done, some defects would be merge after integration in the empirical world, which requires further discussion across teams to resolve the issues.

Nexus Integration Team mindset is the solution

Overall, having the right mindset is the most important part to deal with complexity and unpredictability in software development. The three issues I mentioned above, including meetings, tools and shared work are only symptoms of a more fundamental problem, which is having everybody in the team to embraces changes. Not just the self organised development team, but also leaders of the organisation to understand agility.

Do you have experience in scaled scrum, such as SAFe or LeSS? Any feedback is welcome and I look forward to learning from your feedback.

Pseudo-scrum – a hybrid of waterfall and agile

Let me tell you the truth: you’re not agile. You claimed to be a scrum team, you did all the ceremonies: standup, demo and retrospective, you got all the tools: JIRA, user stories and scrum board. But still, there is something fundamentally missing if the mindset is not right. Here is why:

1. You have a strict roadmap

In other words, you have a hard deadline of the whole year. Scrum team does estimation per sprint planning and get the measure of velocity. How can you tell if the scrum team can deliver according to the guesstimate from senior management? It is a waterfall approach if the roadmap is strict, the scope is fix and the release plan is not based on realistic fact.

2.You don’t have a scrum master

You got one in your organisation chart but what is his job title? Likely he is not a full time scrum master, but with the job of project manager, producer or senior developer who is not dedicated full time to perform the role. Things start to go wrong when the scrum master is also the developer and the product owner. Even if you have a scrum master, it is very unlikely he would be able to resolve the true impediments either because the problem is too technical or beyond the level of his job title to resolve all dependencies.

3. You don’t have a product owner

It is a very important role but he is usually too busy from doing it right. Backlog needs to be prioritise, but every stories are equally important when there is no vision, when the requirements come from other external senior directors and when the features developed are going to be wasted. The product owner is responsible for the decision but very few people can take the risk, while many people don’t even know what they want.

4. You don’t have a budge

Story point is not a tool for budgeting. It can no longer reflect the true velocity of the team, because you either over estimate for more money and for more buffer time, or you underestimate during negotiations for story points to lower the budget. Meanwhile, the traditional accounting approach is not adapt to agile. Money is the root of all evil to burn out the scrum team while still not getting the expected result.

Manifesto in my own words

Response to change over following a strict roadmap from senior management. Individuals and interaction over office politics. Working software over long hours of meaningless meetings. Customer negotiations over budget negotiation. That is, not easy to achieve, but I believe this is the way to transform a bureaucracy company to thrive in the digital world.

Things I learned from IoT project

It was challenging to work on an Internet of Thing (IoT) project for a bluetooth smart device in the last year, which is different from pure software development in a couple aspects:

Firstly, integration is difficult, because the mechanical, firmware, mobile app and design parts are outsourced to different vendors with geographically remote teams and different work culture. Full scrum approach is not likely to apply when the developers are so specialised in its own area as silos instead of cross-functional to deliver one feature at a time as a whole team.

Secondly, the iteration of hardware is much longer than software, which is not easy to adapt to change. Lots of chips and motherboards are interconnected, unlike software can be easily modularised to separate components and implement features one by one. Therefore the approach is more waterfall as you either get the prototype as a whole or you get nothing, no in between for most valuable product (MVP) to ship to users to test, thus no users feedback input to the process, nor prioritisation of features. The longer the time, the larger the risk that you lack of courage to give the product to the end users because you afraid it is not perfect.

Thirdly, when things do not work, it is almost impossible to identify the problem, whether the main reason is mechanical failure, firmware bug or mobile app development issue. End to end testing is harder to achieve with the interface keep changing. It was also time consuming to test without full automation of the hardware and generate expected signal to the software. Better solution is to write down all acceptance criteria, with each statement actionable and testable, either pass or fail, no partial acceptance, thus enforce a strict definition of done.

Overall, properly deal with failure in communication is the most important factor to ensure the success of I.T. project. It is a natural behaviour for people to point fingers at each other when things are not working, thus leads to defensiveness and damaged the relationship among silos. The right way for good communication is to stop your tendency to evaluate, judge or disagree from your point of view emotionally. Instead, please try to listen and understand what is actually happened from the other person’s point of view.

This approach can reduce the amount of time and effort wasted in the process, leads to attitudes that are more positive and more problem solving in nature, thus achieve higher performance. High performance is measure by the value delivered to the end users. I wish the final product will be released and see the satisfactory and happy faces from the users.

Do you have experience in IoT project? Did you face similar problems? I’d love to hear your story and learn from you as well.