Do Agile Methods - Scrum - Motivate your Team?

2016 02 01 head

Decision makers and waterfall aficionados loudly ask if agile approaches are worth the hype.

Does the approach really promote team work?

Well, my current experience is that the answer is a sounding YES.

Developers love to develop software products using Scrum. The motivation and positive energy just explode.

People talk together, build as a team better products and enjoy the daily activities.

Stakeholders and customers or users embrace the advantages they get.

A whisper can still be heard:

Yes, it is not without consequences for the organization.

Say your team is developing software products with Scrum. We have the following roles:

  • The stakeholders

  • The developers (Development Team)

  • The Scrum master (SM)

  • The product owner (PO)

The Scrum Team is the composition of the development team, Scrum master, and the product owner.

Stakeholders

Stakeholders love Scrum. Every two weeks they have a new application version they can use, test, and get feedback from all users. This is the dream of every key account manager.

Because a new release is available every two weeks, the stakeholders should also provide feedback every two weeks. They sometimes hate the pressure of agile and Scrum.

Some organizations struggle with high-delivery rhythm. Explain to your stakeholders a new release is available every two weeks. The stakeholders decide how often the solution is deployed into production.

Developers Team

Agile methods, such as Scrum, eXtreme Programming, or LeSS, are fun for all developers. Suddenly, everyone can see your code, so at the beginning you as a developer must cope with different views how good code should be written. Suddenly, you must master Test Driven Development TDD, mocking, unit test, legible documents. But once you have it, you start to experience the "flow" and enjoy the atmosphere and to deliver at the end of each sprint a new software artifact.

You realize later that Scrum says the team is responsible. You must acknowledge that product success is also your success. ROI considerations now also drive each design decision. If you master these responsibilities, you suddenly discover the world of engineering. It is creating great products with an optimal balance of external quality and costs without ever jeopardizing the quality of the core. You can never again deny that you as a developer are in charge.

Scrum Master

The Scrum master [1] is cool with a team enjoying Scrum and the flow of success. You have to realize you are not a master. You are the enabler for a team of talented engineers.

So you need to discover your the lonely cowboy riding in the sun song why this job is so rewarding.

Product Owner

As a product owner [2], you control the budget of the product, the priorities. At the end of each iteration, you can change all priorities and goals. Cool isn’t it. But wait as a product owner, I am responsible for the budget and product success, and each time a member of the team asks me something I must have an answer ready.

Scrum is cool and we enjoy it. And Scrum makes everything transparent and fast. Every two weeks, a new version is delivered. This version must be evaluated, accepted or a list of improvements must be provided in the next few days. This rhythm is fast, really fast. Once you are up to this speed, you will enjoy the flow.

Lessons Learnt

Middle management often struggles with the agile approach at the beginning. See, for example, the discussion about manager role in an agile environment in the LeSS approach. Be assured the results are worth the effort.

Reading an experience report or digging in the findings of Kotter, you realize success or failure goes through how you handle middle management.

References

[1] S. Ockerman and S. Reindl, Mastering Professional Scrum. Addison Wesley, 2019 [Online]. Available: https://www.amazon.com/dp/B07XTLNPTC

[2] D. McGreal and R. Jocham, The Professional Product Owner. Addison-Wesley Professional [Online]. Available: https://www.amazon.com/dp/B07D5ZPJBY