Simon Reindl

​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!

Overview 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 focussing on the transport, not the destination. The objective is to deliver value to the business faster, Scrum is one of the most effective ways of achieving that, however it is not the only way. It is also not the goal in itself. An analogy is a holiday. The destination is where you are going for your holiday, the way you get there is the transport. Your transport is determined by your destination and constraints. If Business Agility is your destination, then an Agile framework is a better transport. How you use the transport will affect how smooth the journey is. Focus on the real goal Now that Scrum is 20 years old, it has achieved a wide adoption to varying degrees of success. There have been a few blogs posts with a theme of the failure of Scrum and Agile. Reading more deeply the frustrations that are being expressed are around the half-hearted adoption, and lack of organisational engagement. Change is hard, particularly when it is as radical as moving from the project to the product mindset. As Ken Schwaber has stated “The pain of adopting Scrum has to be less than the pain of not adopting it” “It takes great effort to follow the rules of a pull system … thus a half-hearted introduction of a pull system brings a hundred harms and not a single gain” – Taiichi Ohno. The focus of the organisation must be on improving the value of the products and services to their customers. The changes to the organisation need to be implemented in a gradual (in reality an iterative and incremental) way. It is next to impossible to use a predictive plan to enable your organisation to behave in an Agile way – it is too complex to build a fixed plan. Use Scrum to get Scrum “Scrum focuses on being agile which may (and should) lead to improving. Kanban focuses on improving, which may lead to being agile.” - Karl Scotland [caption id="attachment_21992" align="aligncenter" width="554"] Scrum: Drink your own champagne![/caption] The Scrum framework is built on Empiricism, and provides many mechanisms for reviewing feedback. Having structured inspection points is a key method of managing risk, which is critical when you are redirecting corporate culture. Changing the corporate mind-set from Project to Product Reporting to Delivery Managing to Leading Cost to Value Control to empowerment It is a wholesale pivot in culture, and needs to be undertaken with energy, enthusiasm and compassion. People will be rightfully concerned about what is going to happen to them, and their concerns need to be addressed respectfully. By using an organisational change backlog, iterating through the changes in an open transparent and engaging manner will allow the organisation to optimise the transition. This is described in more detail in the Agility Guide Remember, Scrum isn’t the goal, being a more efficient value focussed organisation is!

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). Phase Tester 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. Analysis Focus beyond the “happy path” scenarios. Be clear around boundary conditions, exception handling, and failure and exception management. Design Challenge 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. Deploy Have 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.

One of the key foundations of helping your business become Agile is the use of empiricism. Empiricism is the scientific approach based on evidence, where any idea must be tested against observations, rather than intuition. Empiricism is based on three pillars: transparency, inspection and adaptation. Adaptation has many synonyms, of which ‘change’ is the most common. One of the reasons that I like working within the Scrum framework is that there are clear learning opportunities built in – otherwise you need to put these in yourself. After a short time you and your team should reflect on what has happened, and how it affected the performance within the team. Building on the better understanding, the team should decide what they will do to enhance the good things, and remove the bad things – that is you should focus on changing the environment to be better. This means that things will be different. If the situation is not different, then you have not acted on the learning (or your team are perfect). In the movie Groundhog Day, the weatherman (Phil) realises that he is repeating the same day. He then goes wild and breaks all the rules, and after he gets bored and then focuses on improving. He then makes each day a little better than the previous day – until he gets the perfect day. The resistance to change that he suffers at the start of the movie is similar to how teams struggle to enact change. Image courtesy of renjith krishnan at FreeDigitalPhotos.net I have seen a number of teams get stuck because: 1) They try to change too much 2) They don’t see anything to change 3) The team is changing at a rate faster than the organisation can accept Try to change too much Limit the number of things that you are going to change. If it is a significant or challenging thing, then only take one action. Talk about this item in each daily scrum (aka stand-up) Nothing to Change There are two extremes for this mindset, one extreme is being overwhelmed, and the other extreme is that of not seeing any way that the team could work better. In both situations a way around this is to focus on a clear vision. If the team have a common goal, then the current state can be compared with that goal, and then find the one change that will give the most benefit for the least effort. Once a change, no matter how small, is enacted then you are moving and the momentum can grow. Team vs Organisation change Often the smaller teams (development and scrum) gain the insight that agility is a continuous process and a mindset, not a state. Many organisations and leaders think that agile is a silver bullet, that gets invoked and that is all that is required. The organisation needs to move to the mindset that things will be different, every day, every week. That is at the heart of business agility. Helping this understanding take hold at a wider level is the responsibility of all the people helping develop the agility of the organisation. Depending on the organisation using a framework may help – the structure provides the robustness needed to embed an enduring change. You will know your team is actively being agile when you use the phrase “for our team, we have found …” to describe your ways of working- regardless of what framework you started out with. Your team will have developed into a state of continuous improvement, using agile tools and techniques to deliver a better product, more frequently.

A common challenge for businesses developing new products is having a coherent and universal understanding of what the value proposition for the organisation is. This will depend on the type of organisation: A commercial organisation is primarily driven by making profit, where a non-profit organisation would focus on a societal benefit. The value proposition is the reason that the organisation exists. From the customer perspective: Value = Benefits – Costs There are 2 ways to increase value then, increase benefits or reduce costs – and that is a topic for a later blog. “So what?” you may think, “Why should I in my role need to know, it isn’t part of my job!” There are 3 critical reasons for this: 1. Building a greater team 2. Collective ownership 3. Purpose All of these factors affect how the people who make the business operate go about their daily work, and it is essential that they are all striving for the same thing. This is often visibly demonstrated in successful sporting teams, where the side with the strongest team ethic achieves most. Imagine a rowing team, when they are united in direction and collaborating together, progress is smooth and fast. When they are not working together, the result is chaos – clashing oars, careering around, even capsizing. Building a greater team We people love to belong. Being part of a team supports our sense of identity and helps us feel good. When we can identify with a team we will proudly state “I am a part of <insert group name here>”. When this happens we will work harder to make sure that the team succeeds. We see this every day when we benefit from great service. Let me introduce Zappos, who have built a great business around their people – so much so that they share their learning .Zippos has built this into their corporate identity, and is growing as a direct result of this team ethic in the Zappos family. Collective Ownership This moves the responsibility for tasks and products from mine or yours to ours. This subtle and profound shift in thinking results in a wider discussion, and regular open challenges if people don’t meet the expected standards. In high performing teams, the correction will be made by the person who made the error, and their colleagues will support them and praise them for fixing it. This is a movement away from blame to continuous improvement. If someone is not meeting the standards then whoever notices this will challenge and encourage the transgressors, it is not reported to a manager, or fed in to a process. This results in prompt correction, before any potential impact of the error (lack of quality) can affect any other part of the business. This then sets the conditions for a mind-set of continuous improvement to be adopted. Purpose In “Drive” Dan Pink identifies this as one of the three motivations for people, regardless of nationality and culture. It explains why people volunteer and spend so much time on open source software projects. Once we take the urgent needs of housing, food etc. away, then this is what helps people go out of their way to do something. When we satisfy this need at work, we can channel everyone’s energy into productive activity instead of the churn caused by not understanding what is meant to be accomplished. Clarity of Value Therefore, to enable everyone to be a champion for value, we need to articulate the value proposition in a clear and simple way that everyone can relate to. This must be an understanding that all in the organisation “get”, as opposed to generating some generic artefacts and posting them on the company intranet (mission, vision, values). The artefact without the deeper understanding is effectively useless (http://cmorse.org/missiongen/). Not Cargo Cult The term Cargo Cult describes the behaviour where the belief that following certain practices will bring a real benefit. This was widely witnessed after World War 2 where Melanesian Islanders built runways, bamboo control towers, and mock aircraft in the belief that aircraft would arrive supplying food, clothing and medicine. In many instances there is a duplication of practices that successful companies use, without the broader understanding of the reasons behind the practice. This is often seen in Agile adoptions, where the implementation of a task board and a daily gathering is deemed to be a successful Agile adoption. In my experience this simply confuses as people as they have more time to collectively wonder what is meant to be going on. You can fall in to the same trap with a value statement for the organisation – to be useful there must be a continual discussion around how each division, team and person is adding to the value of the organisation. Call to action A few questions for reflection What is the value proposition for your company? What is the feature or team that you work with doing to grow that value proposition for the organisation? Does the person who sits either side of you have that same understanding? When did you last take this value proposition out and examine it, service it, and make certain that what you are doing builds towards it? If you don’t focus on value, your competitors will.