Simon Reindl

"Becoming Agile" has been the focus of many organisations for a number of years. 2020 has created a new sense of urgency with a number of factors creating increasing demand for quicker responses.

The traditional approach of RFI – RFP – Review – LOI is neither lean or agile. The Lean Agile Procurement approach reduces the sourcing cycle time to days, with collaborative clarification of the product with prospective partners while reducing the risk of a poor partner and company evaluation.

The purpose of Scrum is to create a potentially releasable Done Product Increment, in order to realize business value. Many teams struggle in improving their Definition of Done. The technique described here allows for greater transparency on what the Definition of Done is, and what the next steps are.

Working with the Professional Scrum Trainer community, and particularly with Ken Schwaber as one of the Professional Scrum Master Stewards has been a very rewarding learning journey.

There is often confusion when organisations transition to an agile way of working, particularly with the mapping of roles. This blog explores the role of Project Managers in Scrum.

Work is complex, and to honour the empirical approach is harder. It requires trust, in order to be transparent. To enable the responsiveness that agile promises there needs to be discipline and rigour.

I am enjoying the Vikings series with my wife, and it inspired a metaphor I have been using when discussing Scrum and Agile Roles within the Scrum team. The roles in Scrum are like the roles on long ship, and the purpose was either trade or raiding. The crew of the ship work together to get to their destination and back. The key purpose of Scrum is to build and deliver a potentially releasable increment every Sprint. The Scrum Team works together to ensure that what they build in each and every Sprint is of the highest possible value to the organisation or purpose that they serve. Scrum has three roles, each with a different focus and accountability: Product Owner (Green figure) The "What". With a focus on Value, time to market, return on investment and Total Cost of Ownership. Development Team (red figures) The "How". Focus on building something that is Done – that the increment is useable and potentially releaseable Scrum Master (blue figure) Ensure that the Framework is understood and is used correctly for the business and the team. Helping everyone understand how to use the framework to derive maximum value and respond to the needs of the Market. They will also remove impediments that are disrupting the Scrum Team's ability to achieve their common goal. There is a supporting interlock between the three roles, with each role creating the environment and understanding for the other roles to perform to their potential. The Viking Ship Metaphor One of the defining characteristics of the Viking culture is that of free will (for the free people, unfortunately not for the slaves). The leader would provide a direction, however the position itself would not automatically grant obedience. However once at sea, the ship had a captain. Before setting to sea, the Captain would need to find a crew that agrees with the intent of the journey (where to raid, trade or explore). The Captain Would choose the direction and navigate the ship. They would use their experience and understanding of the conditions to steer the ship towards their intended direction. Storms were to be expected, and there was a need for constant adjustments as in any sailing. The captain has the authority to steer the ship, and the duty of care to the rest of the crew to find the best destination for them. In Scrum - this is the Product Owner. The Product Backlog is the steering oar. The Crew When needed, the crew man the oars and row the ship, or manage the sail. They are the ones responsible for keeping the ship moving to and from the destination. In Scrum - this is the Development Team. They use the tools and environment available to them to deliver a steadily growing increment of “Done” product. The Bosun Perhaps this is not historically accurate - but it helps in the metaphor! There is someone who ensures the right things happen on the ship. Help everyone know what their role is, get the ship rigged for the weather, when to ship oars and bang the drum to row in time, etc. In Scrum - this is the Scrum Master. Visualising this: Without a Development Team, there is no progress. Without a Product Owner, the journey lacks direction and focus Without a Scrum Master, the hidden dangers can halt the journey As a full team, the destination is arrived at through focussed effort. Mixing the roles A recurring question is can a person occupy multiple roles? Using the Ship metaphor, we can discuss the potential impact of being in multiple roles. There is a probability that the person will focus on what they get the most satisfaction from, leaning towards the activities that they like the most. Will they go to where they are most needed? How will people know what role they are performing? Sometimes it is more obvious where their efforts should be directed. It is likely that this will disrupt the smooth running of the team. Remember that a functioning and performing team has a dynamic that is characterised by the interactions between the members. There is no fixed rule on this, as each situation is unique. The common effect is that neither role is served effectively, or one of the roles is not serviced at all. Product Owner and a Development Team member Do they want to steer or row? There is probably going to be times when the ship is not steered as they are rowing, or the ship will go more slowly as they are steering not rowing. Scrum Master and a Development Team member Do they want to bang the drum or row? There is probably going to be times when oars clash as they are not banging the drum, or the ship loses momentum as they are drumming not rowing. It might just happen that the ship moves fastest when they are banging the drum. When there is a new team member, who will help them understand how to work the ship? Product Owner and Scrum Master Do they want to drum or steer? The conflict of interest between the two roles affects the team and the product. The natural tension between product and framework is upset. Serving many teams I have worked with far too many organisations that encourage one person to serve multiple teams in all roles. When you time share across teams it is challenging to be fair to all the teams equitably. Typically, it is the team that is making the most noise that gets the attention - that may not be the team with the greatest need. This is particularly noticeable when an organisation starts to scale their product development. In the longship metaphor, they spend most of their time swimming between ships – or the ships have to slow down so that they can climb from one ship to another When the storm hits... In sailing when the storm hits, you need all hands on deck. You need to keep steering the ship into the waves, or risk capsizing. If a big enough wave hits from the side, you sink. Every member of the crew needs to perform their role effectively in order to keep the ship afloat. If we keep with the metaphor, the storm is the unexpected events that occur in product delivery. When the unexpected happens, without having the people committed and focussed to perform their roles then the unexpected may capsize the product - ending it or pushing it off course. Where the metaphor breaks down… The Product Owner needs to trust the team within a Sprint and let them focus on achieving the Sprint Goal – this is unlikely in a long ship. The Development Team have the freedom to adapt the architecture and shape of the Product to ensure that the product is releasable – this is not addressed in this metaphor! During the Sprint the Product Owner should allow the Development team to self organise in the way they deliver the Sprint Goal. The Scrum Master adopts a Servant Leadership style, using an “Ask don’t tell” stance. No Whip, no orders. How are you sailing? A special thank you to @N__Hutchinson who created the images for this blog!

​ Table Manners There is a striking similarity between good table manners and good agile behaviours - "agile table manners". It is even more clear when viewed through the lens of the Scrum values: Focus, Respect, Openness, Courage and Commitment. The intent of manners is to help it be as safe and pleasant to be with our fellow mankind. Many of them stem from safety and hygiene, and others from a desire not to offend. These simple rules act as a guide to encourage each meal to be as joyful as possible. The same can be said of working within an agile mindset. A host always ensures plenty ​A good host will always ensure that there is enough to feed everyone, and there is a healthy variety. In some cultures, it is important to leave a little food on your plate to let the host know you are well fed. In Scrum it is critical for the Product Owner to ensure that there is a healthy backlog, of well refined work for the Development Team to select from. This should be refined with the Development Team as well as other experts as necessary. In Kanban this may be a specific board before the Development board, to shape the understanding of the work. If there is not enough well understood work, then the team will either be idle (going hungry), or take on poorly understood work (and choke). Don't overload your plate ​When you serve yourself, you shouldn't take more than you can eat. Be mindful that others will need to serve themselves, and that you can always go back for more. When teams are selecting work, select enough to be busy, and not so much as to leave any left over. Finishing a Sprint with undone work is the key sign that too much work was selected. There will be times when this happens through illness or other unexpected events - it should not be the norm. If all the work is finished, then the Development Team should always talk to the Product Owner about how to drive the most business value from the time remaining. In Kanban, the teams should be reflecting on their WIP limits and monitoring flow through the entire process. The throughput should indicate how overloaded the team is. It is rude to offer someone what you have half eaten yourself ... just as it is disgusting to spit out chewed food and put it on your plate - Erasmus Finish your mouthful ​This is a huge one. In practice, so easy. Take a reasonable mouthful, chew it well, swallow. There are some key etiquette points around this: Don't talk with a mouthful (and spray your fellow diners) Don't shovel more food in with an existing mouthful (and risk choking) Don't spit out half eaten food, and take another mouthful in Don't take such a big mouthful that you can't chew it In our working day, how many times is there a partially done task? How many times do you start one task, put it down and then start another?​ This is the essence of context switching, and is an incredibly common waste. This is explored in ​this article by Jeff Atwood and ​this article by Matt Stine. There are tasks that are suited to checking with other tasks, or the bigger plan. At the "mouthful" size - the task should be finished. Use the​ pomodoro technique to break your day in to manageable chunks. Re-evaluate what you need to next after you complete each "mouthful". Don't force feed others ​You should only feed someone else by invitation! This is not to be attempted unless clear and unequivocal permission has been given! At best, it is messy, at worst it is dangerous. How often do you push another mouthful onto someone else? The agile frameworks are all pull based to enable better flow. When we push work we create bottlenecks and buffers. How do you feel when someone gives you tasks without talking to you about it first? This inhibits the ability for the team to self organise. Ben Day explores this in the ​this article. Assigning work out can impede the team developing the essential skills of self organisation. Summary ​Working together should be as joyful as possible, so behaving in a respectful way will help each interaction with someone else as fun as possible. If we thing of our work as "food for the mind", then surely we should use good table manners while eating our food. Good Eating!

Working with a range of people, it is interesting to observe how many are aiming to “Do Scrum” or “Get Agile”. The issue with this thinking is that people are focusing on the transport, not the destination.

An agile development team is cross-functional, meaning that as a collective the team has the capability of building a potentially releasable increment (the working software). Given that testing is focused on verifying the behaviour against expectations, and that the whole team is collectively responsible for quality – what does the professional tester do for the team in an Agile world? My assertion is that the role of the professional tester in an agile team is that of the quality coach, as well as completing their work within the development team. To be effective the tester needs to coach the team through every stage of the lifecycle, from requirement to completed product, by helping the team be clear around the tasks of each phase. By doing this the tester can ensure that the business are clear about what they are building (build the right thing), and the development team comply with agreed quality standards (build the thing right). PhaseTester activity Backlog Refinement (Requirement Gathering)Ensure that there is a common understanding around what is being requested. Have clear, unambiguous acceptance criteria.Help the business be clear on the value proposition for each item. AnalysisFocus beyond the “happy path” scenarios. Be clear around boundary conditions, exception handling, and failure and exception management. DesignChallenge the team to consider the impact of the design on: Performance Load Scalability Accessibility Penetration Globalisation Be clear with the other team members on how this will be tested. Develop (build and test the increment)Create and execute on the test planBe clear that the other team members will need to be engaged in the creation, execution and maintenance of all the tests – automated and manualMake the build process include testing, and fail when a test fails.Keep the feedback loop as short as possible between a code commit and feedback on the quality.Challenge the team to extend the testing techniques used.Test the deployment in an environment as close to live as possible. DeployHave a test for the deployment of the product.Have a smoke test plan – a series of tests that will confirm whether the product has deployed correctly in to the environment, and that the product is working.Make sure that other teams can keep working after your team’s changes are merged through to their code. Focus from the outside in When you are working on the product, it is important to start working from the highest level (the desired value proposition), working through the successive steps in to the granular detail of the individual code (unit) tests. Why build something that is of no value or use? Tools and Techniques There is no single tool or technique that will allow your team to achieve all their goals. It is important that you continually explore new tools and techniques to improve the way your team achieves the agreed quality standard. Read blogs from Testers you respect Go to user groups – Meetup is a good tool to find events close to you Check updates from tool companies that work on your technology stack (home page) We often forget to look around us to build up communities within our own organisations, this will help us to grow the focus on quality Call to Action When you’re working within an agile team, finding bugs is a by-product of having a focus on quality throughout every phase in the product lifecycle. Challenge yourself and your team to focus on quality – and aim for less bugs in each and every build.