tag:blogger.com,1999:blog-45790320089930183102024-03-13T02:55:35.156+01:00Agile Project Management and CoachingThis blog contains post regarding doing projects the Agile way.Christo Martenshttp://www.blogger.com/profile/05488782784811298877noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-4579032008993018310.post-73193353817518720732021-01-14T10:02:00.001+01:002021-01-14T10:10:22.178+01:00Engaging in Agile – the more the merrier?<p>As a project manager and scrum master, I often get the question – why do suppliers sometimes offer a separate engagement (or contract) manager on top of the one or more Agile teams that are asked for in a request for proposal? In Agile environments, teams are self-organized, and the product owner is the only person in the team that makes decisions on scope and delivering the most business value with the available budget. So, why in some cases is such an engagement manager still added to the service offering?<br clear="all"><a name='more'></a><p>In this post, that I have originally published <a title="Engaging in Agile – the more the merrier?" href="https://www.capgemini.com/2020/12/engaging-in-agile-the-more-the-merrier/" target="_blank">here</a>, I will answer this question by first looking at a basic Agile team situation and then how making this situation more and more complex by hiring staff creates a client supplier relationship. This blog won’t go into detail on the processes of the hiring of the organization itself, for example, contracting, budgeting, and (financial) reporting.<p><strong>The basic Agile team situation</strong><p>The simplest situation is when an organization that starts working in an Agile manner only uses its own employees. It assigns a product owner and provides this person with the mandate sufficient to deliver value. Next, a development team has to be found that can deliver the requested value using its knowledge of processes and technology. Finally, a scrum master is assigned to the team to facilitate the team and coach it towards an Agile way of working. The agile team is now complete – It just has to deliver.<p>If stakeholders in the organization aren’t happy with the result (the delivered business value), they contact the product owner and discuss their doubts. The product owner can adjust priority, and the Agile team can try to improve quality or velocity, or the Agile team can decide to switch team members when a required skill isn’t available within the team.<p>A clear situation without a lot of responsibility issues, I would say.<p><strong>Hiring separate staff</strong><p>A bit of a more complex situation arises when the organization doesn’t have sufficient resources to staff the team. Such an organization might want to wait with delivering the intended business value until the necessary staff is available. However, there’s often a need to actually deliver this value in the near future – and a decision is made to hire specific staff. Usually the hiring is limited to the expected time of the project.<p>The only difference with the previous situation is when the hired staff member has contractual issues (like underperforming, leaving early, or an early project-end) or when the project has an extended end date. In this case, the hiring manager is responsible for solving these contractual issues with the hiring party – either with the self-employed person directly or the staffing manager of their employer. The more staff has been hired, the more time the hiring manager will spend on managing these contracts – but overall, it remains a very clear situation with reduced complexity.<p><strong>All in on Agile – hiring an entire Agile team</strong><p>Complexity increases when an organization lacks a lot of staff with specific knowledge and decides to hire an entire development team with or without a scrum master. Of course, this hiring can be done on an individual basis, which would be similar to the previous situation. However, organizations often hire an Agile team from a supplier with certain expectations regarding results or even specific KPIs.<p>Neither the relationship between the organization and the supplier – nor the result or KPI expectations – are covered in Agile ways of working. While it is not in accordance with a pure Agile mindset, it is a daily practice in a lot of organizations. The situation inside the Agile team looks almost the same as in all previous situations. However, the situation at the supplier has suddenly changed. The contractual expectations (agreements) regarding results or KPIs have to be managed. Within some contracts, a penalty clause is present. These clauses result in financial risks for the supplier. Someone should be made responsible for managing the contract and its risks. This is the supplier engagement (or contract) manager role, and not the scrum master role. The latter serves as a leader of the team with its dedicated responsibilities, for example, facilitating the team, coaching the organization, and removing impediments.<p>The engagement managers won’t manage scope or budget, as long as it’s not in the contract. But when there are contractual obligations regarding these topics, they will manage these and take responsibility. They will also be the first contact on staffing or finance-related questions. Hiring multiple teams definitely makes the engagement manager’s job more complex due to the span of control.<p>So, by adding an engagement manager to a team-hiring contract, the related contractual matter can be handled out of the Agile team’s sight – and the team can keep its focus on delivering business value to your customers.Christo Martenshttp://www.blogger.com/profile/05488782784811298877noreply@blogger.com0tag:blogger.com,1999:blog-4579032008993018310.post-46699577592052409882020-10-26T15:55:00.019+01:002020-11-16T14:32:17.632+01:00Agile basics and working remote<p align="center"><span style="font-size: x-small;">The research version of our Capgemini post ‘<a href="https://www.capgemini.com/2020/10/out-of-office-agile-agile-basics-in-a-remote-work-world/" target="_blank">Out-of-office-agile - Agile basics in a remote world</a>’</span></p><p>Working from home is becoming more and more common nowadays. People increasingly want to work from home. This change has been boosted by the Covid-19 pandemic. Due to the consequences of the pandemic, we were forced to work from home. Mankind ran quickly into solutions to keep the work going but took little time to inspect and adapt. As this situation was expected to be temporary, people didn’t feel the urge, did it superficially or focused only on the obvious. Still the situation and its urgency, might have caused overlooking the basics of working agile and its underlying principles.</p><p>As it now turns out not be a temporary thing, we need to have a deeper dive into what’s needed to improve working remote or even from home. In this article we will reflect on remote working using the agile practice of Inspect and Adapt. </p><p>The inspection results are based on our own experiences on projects and signals we get from our fellow Agile coaches. To deepen our inspection we choose to use the Agile Manifesto and the Scrum guide. <span></span></p><a name='more'></a><p></p><h4>Inspect</h4><p>Let’s start with an inspect first. In the inspection we have taken the basics of the Agile Manifesto and Scrum as leading source to reflect to. </p><p>The <a href="https://agilemanifesto.org/"> Agile Manifesto</a> has been the foundation for all agile ways of working we know now and will likely will remain to be for future agile methods or processes. That’s why we used the Manifesto and the underlying <a href="https://agilemanifesto.org/principles.html"> agile principles</a> as a source for our inspection. Because we see that Scrum is kind of the starting standard, we also took the <a href="https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum"> pillars</a> and <a href="https://www.scrum.org/resources/scrum-values-poster"> values</a> of Scrum into account.</p><p>We have done the assessment on the possible risks, by evaluating these agile basics one by one as a viewpoint to identify risks. As the next step we grouped them into potential common grounds. The ‘brown paper’ inspection results are in the <a> appendix</a>. The communality is presented in this chapter in four common grounds.</p><h5>Not being together</h5><p>Well, this is of course the obvious one. Because of working from home, the interactions between people can be hampered and we become more reliant on tools. We run the risk of not picking up conversations between two other people in the room where we might have a valuable contribution. Natural discussions aren’t popping up the way we want it. And we even miss out on possible improvements that can be made to the product we are working on.</p><p>The tools used can be broken or people have the fear of using them and by that don’t give (all) the input they could give and are less open. </p><p>But there is also the risk, like we see on social media, that people are less restrained in their outings and by that cross the line of respectful interaction with others.</p><h5>Plan and control from outside the team</h5><p>Many agile projects still live in an environment in transition from a plan and control culture to an Agile culture. Because of the remote way of working the team’s result become less visible, the management gets less information. </p><p>Organizations might fall back on the traditional plan and control to track progress. And even fall back to contract negotiations. But also, because the team dynamics might be disturbed, the team itself loses it trust in being self-organizing and falls back into asking the manager what to do.</p><h5>Focus issues</h5><p>We see people either losing their focus when working from home or going in hyper focus. Losing focus because of missing the stimulus from colleagues keeping a person sharp or disturbances in the working from home situation. Hyper focus because of the lack of healthy disturbances. Both disturb a sustainable process flow.</p><h5>Skip inspect and adapt</h5><p>The last major thing which might happen is that teams are skipping the inspect and adapt cycles. Reviews are not happening because the tools don’t work, or people have a fear to use them. Or even worse, they use it as an excuse not to attend.<br /> But even when the official inspect and adapt moments are planned, people are just going through the motions and are not really focused and committed to the event. Being unable to look each other in the eyes, we get limited information and we miss the signs triggering to ask a deepening question. This causes the real reasons and possible solutions for problems not to surface.</p><h4>Adapt</h4><p>During our inspection we have identified four possible common grounds of problems arising with remote working. We now can take measures to reduce their impact or even prevent them to happen.</p><h5>Not being together</h5><p>Because this is the most obvious root cause, most teams have taken already some action. Like using live meeting tools for at least the standard ceremonies. Still, inside and outside these ceremonies a team can take measures to come as close as possible to being together. Examples of these measures are:</p><ul style="text-align: left;"><li>Setting up one single team chat channel, where every team member is taking part. And to use this channel to start a discussion, even if the question is directed to one special person. So, everybody can jump in, if he feels the urge. It might even be good to jump in when one doesn’t feel the urge as you might hear interesting discussions.</li><li> As a discussion lengthens, go separate with only the people involved. Or, go into a direct call, when a discussion intensifies. Like if you talk too long when in the office and by that disturbing the people around you, you go into a meeting room.</li><li> People that attend a session or ceremony should have their video on. This increases the feeling of being present and reduces the chance of being distracted by unimportant matters for the session. The microphones should be muted if participants are not speaking to reduce background noise that could distract others.</li></ul><h5>Plan and control from outside the team</h5><p>The main reason for managers to go into a plan and control mode is the lack of visibility of the team and its progress. Therefor the counter measure can be found in this area.</p><ul style="text-align: left;"><li>Invite these managers more frequently to the sprint review than you are used to. During the review they can see the team at work while showing the progress made.</li><li> Because the review becomes of more value to managers, it should be prepared with more care, to make it a smooth journey. However, this doesn’t imply that more preparation time should be taken. Rather the development team keeps the review in mind during the sprint while working on the backlog items. This could result in a slightly extended Definition of Done.</li><li>In a face-to-face situation a physical Kanban board is often somewhere in the room on a wall. If managers walk by, they can look at it and ask the product owner questions about the team progress or a specific backlog item. To keep the visibility at an as high as possible level, one could consider providing them access to the online boards. Be aware that they cannot change it unwantedly.</li></ul><h5>Focus issues</h5><p>Preventing losing focus or going into a hyper focus, is a hard job in a remote situation. You cannot see and feel the tension people are facing just by being present. What you could do is trying to reduce the chance that team members are having focus issues, or the impact when they actually do.</p><ul style="text-align: left;"><li>As an agile coach, stay in frequent contact with the team members. Have a regular chat, of course with video on, about everything that is going on in the team member’s mind. Be alert on signals of focus issues. Like home mates asking for attention regularly, cats or children making noise, but also if they look tired or have a loss of concentration. So, not only listen to the words but watch the environment.</li><li> Make monitoring this a team effort. Let everybody be aware of this risk and stimulate the social cohesion by inviting them to look after each other.</li><li> And when having team meetings try to put in some fun factor. Things like playing a short game, some team member giving a virtual tour through the house, emulate a lunch walk with everybody in a live audio meeting. Ask people questions about other things in life, next to the job they are on. Like you do in the office.</li></ul><h5>Skip inspect and adapt</h5><p>The worst thing you could do in an agile way of working is skip inspect and adapt activity. It will reduce the team’s capability to learn and improve tremendously. So, the only measure to take, and the only advise is: Just don’t!</p><p>There are some measures to take to have a smooth Inspect and Adapt session:</p><ul style="text-align: left;"><li>Have the proper tools in place. These tools should facilitate collaboration. You could consider tools for sharing and updating sticky notes, whiteboards or supporting specific purposes of scaled ceremonies.</li><li> Be sure to have tested these before. Especially for meetings where stakeholders outside the team are attending, whose valuable input you really need.</li><li> The measure for ‘Not being together’ related to video and voice, always have it on and be muted when you have nothing to share, also applies to this topic. </li></ul><h4>Conclusion</h4><p>There are a lot of pitfalls while working remote in an agile environment. Luckily, the <a href="https://agilemanifesto.org/" target="_blank">Agile Manifesto</a> and <a href="https://agilemanifesto.org/principles.html" target="_blank">its principles</a> as well as the <a href="https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum" target="_blank">Scrum pillars</a> and <a href="https://www.scrumalliance.org/about-scrum/values" target="_blank">values</a> provide us enough guidance in detecting (see the <a href="#appendix">appendix</a>) these pitfalls. Based on our analysis we have been able to identify common measures that could possibly help you in your specific situation. To find the most valuable and useful measure when you work remote, especially now most of you must work from home during the current pandemic, you should frequently do an Inspect and Adapt yourselves.</p><p align="right"><span style="font-size: x-small;">[Authors: <a href="https://www.linkedin.com/in/janklabbers" target="_blank">Jan Klabbers</a> and <a href="http://agilepmandcoaching.blogspot.com/p/about-me.html" target="_blank">Christo Martens</a>]<span style="font-size: x-small;"><br /></span></span></p><hr /><h3><a id="appendix" name="_Appendix:_Inspection_brown"></a> Appendix: Inspection brown papers</h3><p>For the inspect we have done some brainstorming. We have set up a brown paper per subject to inspect the Agile Manifesto and principles, and the scrum pillars and values. These papers contain per item the risk or facts that we came up with. Afterwards we grouped these to find the common grounds. We have found four common grounds: Not being together (NBT); plan and control from outside the team (P&C); Focus issues (FI); Skip inspect and adapt (SIA). The result is shown in the next tables.</p><h5>Agile Manifesto</h5><table border="1" cellpadding="0" cellspacing="0"><tbody><tr><th style="text-align: left;" valign="bottom" width="141"><p>Manifesto</p></th><th style="text-align: left;" valign="bottom"><p>Risk / Fact</p></th><th valign="bottom" width="80"><p>Common ground</p></th></tr><tr><td valign="top"><p>Individuals and interactions over processes and tools</p></td><td valign="top"><p>We need more tools for communication to bridge the physical gap between team members. That’s for sure.</p></td><td style="text-align: center;" valign="top"><p>-</p></td></tr><tr><td><br /></td><td valign="top"><p>When using communication tools so often people might only meet live in a synchronous mode (calls, online meetings) during the standard events and use a-synchronous modes (chat, e-mail) for all other communication due to an overload of online meetings. The latter causes a delay in the communication</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr><tr><td><br /></td><td valign="top"><p>As the physical visibility of the work team members are doing decreases, people might tend to put emphasis on control mechanisms in stricter processes</p></td><td style="text-align: center;" valign="top"><p>P&C</p></td></tr><tr><td><br /></td><td valign="top"><p>People that aren’t at the same physical location are missing out on conversations between other team members and by that missing the opportunity to provide spontaneous valuable insights and contributions</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr><tr><td><br /></td><td valign="top"><p>With less interaction people might get distracted by other matters in their private space</p></td><td style="text-align: center;" valign="top"><p>FI</p></td></tr><tr><td><br /></td><td valign="top"><p>People that are unwilling to participate in meetings might blame the tools for not being able to contribute to discussions. Press your moustache – to use a Dutch saying.</p></td><td style="text-align: center;" valign="top"><p>SIA</p></td></tr><tr><td valign="top"><p>Working Software over comprehensive documentation</p></td><td valign="top"><p>The impact of working from home is very little. Still a proper adaption could be to be more reliant on documentation. If adaptation is done consciously, there no problem.</p></td><td style="text-align: center;" valign="top"><p>-</p></td></tr><tr><td valign="top"><p>Customer collaboration over contract negotiation</p></td><td valign="top"><p>As the physical distance between team and customer increases, people might tend to put emphasis on control mechanisms in stricter processes. And by that more emphasis on contracts</p></td><td style="text-align: center;" valign="top"><p>P&C</p></td></tr><tr><td valign="top"><p>Responding to change over following a plan</p></td><td valign="top"><p>When communication tools malfunction during events, like reviews, demos, stakeholders might not see the needed change on product or process and the team continues working based on the incorrect knowledge</p></td><td style="text-align: center;" valign="top"><p>SIA</p></td></tr><tr><td><br /></td><td valign="top"><p>Because discussions between team members and between team and business is less effective and efficient, they might not see the needed change on product or process and the team continues working with the wrong knowledge</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr></tbody></table><h5>Agile principles</h5><p>As the agile principles form the foundation the Manifesto is built on, we only mention the new insights below.</p><table border="1" cellpadding="0" cellspacing="0"><tbody><tr><th style="text-align: left;" valign="top" width="250"><p>Agile principles</p></th><th style="text-align: left;" valign="top"><p>Risk / Fact</p></th><th valign="top" width="80"><p>Common ground</p></th></tr><tr><td valign="top"><p>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.</p></td><td valign="top"><p>Nothing special here</p></td><td style="text-align: center;" valign="top"><p>-</p></td></tr><tr><td valign="top"><p>Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.</p></td><td valign="top"><p>Nothing special here</p></td><td style="text-align: center;" valign="top" width="70"><p>-</p></td></tr><tr><td valign="top"><p>Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.</p></td><td valign="top"><p>Nothing special here</p></td><td style="text-align: center;" valign="top"><p>-</p></td></tr><tr><td valign="top"><p>Business people and developers must work together daily throughout the project.</p></td><td valign="top"><p>Malfunctioning tools will cause a (strongly) reduced effectivity on customer contact moments like some ceremonies</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr><tr><td valign="top"><p>Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.</p></td><td valign="top"><p>If less visibility or transparency, reduces trust by management and causes them to tend to more plan and control, the team will become less self- organizing and make fewer decentralized decisions.</p></td><td style="text-align: center;" valign="top"><p>P&C</p></td></tr><tr><td valign="top"><p>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.</p></td><td valign="top"><p>That’s the issue and main topic of this document</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr><tr><td valign="top"><p>Working software is the primary measure of progress.</p></td><td valign="top"><p>Nothing special here</p></td><td style="text-align: center;" valign="top"><p>-</p></td></tr><tr><td valign="top"><p>Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.</p></td><td valign="top"><p>Social risk of people being distracted from home</p></td><td style="text-align: center;" valign="top"><p>FI</p></td></tr><tr><td><br /></td><td valign="top"><p>The opposite of being constantly in the zone and don’t take a break or don’t stop in time.</p></td><td style="text-align: center;" valign="top"><p>FI</p></td></tr><tr><td valign="top"><p>Continuous attention to technical excellence and good design enhances agility.</p></td><td valign="top"><p>People might be wandering off because they aren’t corrected by team members</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr><tr><td valign="top"><p>Simplicity – the art of maximizing the amount of work not done – is essential.</p></td><td valign="top"><p>Risk of skipping ‘natural’ peer review, less pair programming/designing/story writing, which can lead to people not seeing the simple solution.</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr><tr><td valign="top"><p>The best architectures, requirements, and designs emerge from self-organizing teams.</p></td><td valign="top"><p>Natural discussion on these topics might be skipped. See former point</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr><tr><td valign="top"><p>At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.</p></td><td valign="top"><p>Risk of not being open due to communication through tools</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr><tr><td><br /></td><td valign="top"><p>People that are unwilling to participate in meetings might blame the tools for not being able to contribute to discussions. Press your moustache – to use a Dutch saying.</p></td><td style="text-align: center;" valign="top"><p>SIA</p></td></tr></tbody></table><h5>Scrum pillars</h5><table border="1" cellpadding="0" cellspacing="0"><tbody><tr><th style="text-align: left;" valign="bottom" width="141"><p>Pillars</p></th><th style="text-align: left;" valign="bottom"><p>Risk / Fact</p></th><th valign="bottom" width="80"><p>Common ground</p></th></tr><tr><td valign="top"><p>Transparency</p></td><td valign="top"><p>Risk of team going under the radar</p></td><td style="text-align: center;" valign="top"><p>P&C</p></td></tr><tr><td><br /></td><td valign="top"><p>Risk of team members to be distracted when they aren’t visible to others</p></td><td style="text-align: center;" valign="top"><p>FI</p></td></tr><tr><td><br /></td><td valign="top"><p>Risk of management wanting to have daily evidence of progress (progress reports on tasks hours spent and estimated) else than working software.</p></td><td style="text-align: center;" valign="top"><p>P&C</p></td></tr><tr><td valign="top"><p>Inspection</p></td><td valign="top"><p>Risk of skipping events – as they are ‘not effective remote’</p></td><td style="text-align: center;" valign="top"><p>SIA</p></td></tr><tr><td><br /></td><td valign="top"><p>Inspections not as effective as being in one room</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr><tr><td valign="top"><p>Adaption</p></td><td valign="top"><p>Risk of going through the motions and settling down with solutions without commitment</p></td><td style="text-align: center;" valign="top"><p>SIA</p></td></tr></tbody></table><h5>Scrum values</h5><table border="1" cellpadding="0" cellspacing="0"><tbody><tr><th style="text-align: left;" valign="top" width="141"><p>Values</p></th><th style="text-align: left;" valign="top"><p>Risk / Fact</p></th><th valign="top" width="80"><p>Common ground</p></th></tr><tr><td valign="top"><p>Commitment</p><p>Courage</p></td><td valign="top"><p>Not being together, can undermine the team spirit and by that the commitment</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr><tr><td><br /></td><td valign="top"><p>You can’t look people in the eyes, the moment they say they are committed – no indication whether they are pressing their moustache (people saying yes and doing no).</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr><tr><td><br /></td><td valign="top"><p>People have a fear of speaking up through tools</p></td><td style="text-align: center;" valign="top"><p>SIA</p></td></tr><tr><td><br /></td><td valign="top"><p>Management might want to increase influence on the process as they cannot see team members showing their courage</p></td><td style="text-align: center;" valign="top"><p>P&C</p></td></tr><tr><td valign="top"><p>Focus</p></td><td valign="top"><p>Risk of lack of focus or hyperfocus because of working conditions</p></td><td style="text-align: center;" valign="top"><p>FI</p></td></tr><tr><td><br /></td><td valign="top"><p>Risk of wandering off while not being corrected by team members</p></td><td style="text-align: center;" valign="top"><p>NBT </p></td></tr><tr><td valign="top"><p>Openness</p></td><td valign="top"><p>Communication by tools might either cause people to not say the things they have on their mind. Or on the opposite state their opinions in an improper way.</p></td><td style="text-align: center;" valign="top"><p>SIA</p></td></tr><tr><td valign="top"><p>Respect</p></td><td valign="top"><p>Distance might cause people to lose respect</p></td><td style="text-align: center;" valign="top"><p>NBT</p></td></tr></tbody></table>Christo Martenshttp://www.blogger.com/profile/05488782784811298877noreply@blogger.com0tag:blogger.com,1999:blog-4579032008993018310.post-61748622032008076752017-06-19T11:47:00.001+02:002017-06-19T13:40:31.309+02:00The Fast and the Furious (and other Fs) retrospective activity<p>Recently I lacked some inspiration for a good technique suitable for the upcoming retrospective. As the team was growing in their agile way of working, I decided to leave it to the team to come up with a nice activity. I was very surpised with the outcome. A brand new activity which we called the Fast and the Furious (and other Fs).</p><a name='more'></a><h5>Goal</h5><p>This activity’s goal is to gather information about the sprint.</p><h5>Timing</h5><p>The activity can be finished in about 30-60 minutes (depending on your teamsize).</p><h5>Materials</h5><p>This activity makes use of :</p><ul><li>Sticky notes and pens <li>One piece of paper (flip-over, brown paper)</li></ul><h5>Instructions</h5><h6>Preparation</h6><p>Draw 5 cells on the paper. This could be either a star, columns or rows. Write in each of the cells the following Words: Fast, Furious, Fun(ny), First and Fed up.</p><h6>Execution – basic</h6><p>The agile coach request the team members for ideas in each of the next categories, and asks them to wirte these on sticky notes:</p><ul><!--StartFragment-->
<li><strong>Fast: </strong>things that went very fast;</li>
<li><strong>Furious</strong>: things that made you furious;</li>
<li><strong>Fun(ny)</strong>: things that were fun or funny;</li>
<li><strong>First</strong>: things that you experienced the first time;</li>
<li><strong>Fed up</strong>: things that you really annoyed you and want to get rid off.</li></ul><p>The team members stick their notes in the corresponsing cells. And have a discussion on their notes.</p><h6>Execution – extended</h6><p>You might want to use different colours for</p><ul><li>each category</li><li>to differentiate between subjects like process, tools, environment.</li></ul><p>Sometimes you need categories as you might want to pinpoint a certain behaviour. In those cases be flexible. There are many English words starting with an F, like Flexibility, so you can find a more suiteable word for your retrospective.</p><h6>Continuation</h6><p>Once the information has been gathered and dicussed the team can define action items to improve themselves.</p>Christo Martenshttp://www.blogger.com/profile/05488782784811298877noreply@blogger.com2tag:blogger.com,1999:blog-4579032008993018310.post-65222063225698997512016-10-26T17:40:00.000+02:002020-11-13T16:06:34.798+01:00The Bug Battle game<p>A couple of years ago, I was the Scrum Master in a project. Though we had a steady delivery of business value, we also noticed that too many bugs were found by our Product Owner. The team knew it had to improve by finding and fixing bugs earlier in the process. Therefore I introduced the ‘Bug Battle’ game. How does this work?</p> <a name='more'></a> <h2>The game</h2> <p>The game has multiple goals:</p> <ol> <li>Improve the quality of your application <li>Teaching that finding bugs can be fun for both testers as developers <li>Team building</li></ol> <h3>Participants</h3> <p>The entire agile team</p> <h3>Timing</h3> <p>The bug battle may take as long as you want, though 1:15 hour is most effective.</p> <h3>Materials<a href="https://lh3.googleusercontent.com/-0BBt2DrC5Ks/WBIE_CRC2jI/AAAAAAAAAP8/NLXDDHHgxHY/s1600-h/Bug%252520swatter%25255B17%25255D.png"><img title="Bug swatter" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; float: right; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="Bug swatter" src="https://lh3.googleusercontent.com/-UKKr-BlFUPc/WBIE_g-_HwI/AAAAAAAAAQA/G7nVSQPIxNQ/Bug%252520swatter_thumb%25255B11%25255D.png?imgmax=800" width="83" align="right" height="240"></a></h3> <p>The Bug Battle game makes use of: <ul> <li>Some nice prices for the winner. I often use bug swatters, because this is close related to the game. <li>A testable application <li>A bug registration tool, both analog and digital tools will fit this purpose <li>A timer</li></ul> <h3>Instructions</h3> <h4>Preparation</h4> <p>In order to have a smooth battle there should be a couple of things arranged: <ul> <li>A team member prepares the test environment. The application that is subject of this bug battle runs in this environment. He or she also takes care of creating accounts for users with all kind of roles. There should be so many accounts that participants cannot hamper each other. <li>All team members should have access from the battle location to the test environment <li>A tester or the agile coach prepares the bug registration tool. Normally this would be the tool that is already being used in the project. If don’t use such tool sticky notes will fit this purpose as well. <li>For huge applications it might be useful to define a test focus. I would choose an area that has high quality requirements or has a high error rate lately. <li>The agile coach or the product owner defines the price winning categories. Be sure that you have a price per category. I have used the categories stated below, but in your situation others might be more useful. <ul> <li>The first bug found <li>The most weird bug found <li>The most bugs <li>The most obvious (but never found) bug</li></ul></li></ul> <h4>Execution – explanation (5 minutes)</h4> <p>The agile coach starts the battle by giving the rules</p> <ul> <li>Everyone uses dedicated users <li>All bugs are reported in the bug registration tool in a reproducible way, so including situation, steps etc. If sticky notes are used reporter name and time are written down <li>If bugs are reported by more than one person, the first reporter ‘owns’ the bug <li>Testing start and end time <li>Test focus (if necessary) <li>Known errors will not be taken into account <li>Any other prerequisites like use of specific tools</li></ul> <h4>Execution – actual game (e.g. 1 hour)</h4> <p>Each team member acts like a tester during the test period by testing the application in a way he or she likes. </p> <p>Once in a while the agile coach mentioned the remaining time in order to keep every in the battle mode. In between he encourages every team member to find more bugs. At the end he announces the closure of the battle.</p> <h4>Execution – awards ceremony (10 minutes)</h4> <p>After the test period the product owner and agile coach go through the reported bugs and decide upon the winner in each category. The product owner compliments the team and especially the winner and rewords them with a beautiful price. </p> <h3>Learning points</h3> <ol> <li>The team members learn that testing need to be done by all kind of roles in the team. People with different focus will detect different kind of errors. <li>Finding bugs is no thread, but can be a fun element as well.</li></ol>Christo Martenshttp://www.blogger.com/profile/05488782784811298877noreply@blogger.com0tag:blogger.com,1999:blog-4579032008993018310.post-45777646026271568272015-10-28T14:59:00.000+01:002015-11-10T10:30:27.031+01:00Ideal iteration length in agile projects<p dir="ltr">A question that always pops up when you start an agile project, is what is the ideal iteration length for this project. As always in agile the correct answer is "it depends". But on what?</p> <a name='more'></a> <h4>Iteration length according to the books</h4> <p dir="ltr">Many books have been written about the agile way of working. Most of these are proving rules of thumb for the iteration length. The most common mentioned iteration length varies from 1 to 4 weeks.</p> <p dir="ltr">In iterations with a shorter length work items hardly can come to Done and there will be an overhead of agile meetings. When an iteration lasts longer than 4 weeks, it is not sprinting anymore and the feedback cycle is so long that the development team is learning too slowly from their experiences. However, non of these gives you the ultimate advise on the ideal iteration length for your project. The reason for that is very simple: it depends on quite a number of aspects.</p> <h4>Aspects influencing the ideal iteration length</h4> <p>I have been involved in a lot of agile projects. Some of them had iteration length of 1 week, some had a 2 week iteration and in others an iteration took 4 weeks. In these project I have experienced different aspects that can influence the ideal length of an iteration.</p> <p>The following aspects should be taken into account, when trying to find an ideal iteration length:</p> <h5>Development speed</h5> <p>The velocity of a team depends on the tools they use. Some tools can deliver much faster than others. A feature can take 1 hour in one tool , where the same feature in an other tool can take over more than a week.So be aware of an average implementation time of a feature. </p> <blockquote> <p><em>The longer a average feature takes to develop, the longer the iteration length needs to be.</em></p></blockquote> <h5>Availability product owner</h5> <p>In an ideal world a product owner is available every minute of a working day. The team can question him or her whenever is needed. However, in practice this won’t be the case. The PO often is responsible for additional non project related tasks. I once did an agile project for a client. We had weekly sprint and this worked perfectly. After that a new project started for the same application, the same product owner and about the same team. However, the project owner appeared to be less available (half in stead of full time). We slightly changed the way of working, but in order to have enough time we also changed the sprint length into two weeks. This worked perfectly and we were able to show the same velocity (in two weeks) as we did before.</p> <blockquote> <p><em>The less availability of the product owner the longer the iteration length needs to be</em>.</p></blockquote> <h5>Availability knowledge and experts</h5> <p>Subject matter experts and the knowledge of the desired application is essential for an agile team to develop the application. When there is a lack of either of these, the development team cannot proceed without doing a lot of assumptions. In such cases an option could be lengthening the sprint or decreasing the team size.</p> <blockquote> <p><em>The longer it takes to get knowledge available, the longer iteration length needs to be.</em></p></blockquote> <h5>Speed of deployment</h5> <p>After some features have been created, they need likely to be tested. Often these test take place in a special environment. The application has t be deployed in that environment. I have noticed that in some projects this takes seconds or minutes, but in others this may take days or even a week. If deployments take days or more a short iteration (1 week) isn’t very practical. The change that there are many untested features by the end of the sprint is so high, that this influences the team motivation negatively.</p> <blockquote> <p><em>The longer the deployment time the longer the iteration length.</em></p></blockquote> <h5>Team size</h5> <p>In general, a smell team can deliver less than an bigger team in an iteration. So, there will be little to show during the sprint review. Besides that, a bigger team will have more experiences and learning points in a certain time frame than a small team. Based on those a short iteration may cause a lot of overhead as the few team members have to prepare the review, have to implement and test the features and have to do all other agile activities. </p> <blockquote> <p><em>The smaller the team the longer the iteration length.</em></p></blockquote> <h5>Definition of Done</h5> <p>The Definition of Done contains all required deliverables for the for a work item (type). These deliverables are project specific. Sometimes just a couple of products need to be realized (e.g. just the code) and sometimes lots of products need to be created (e.g. functional and technical documentation, code, test cases, test data, test results). There should be enough time to create and validate these deliverables.</p> <blockquote> <p><em>The more deliverables in the Definition of Done the longer the iteration should be.</em></p></blockquote> <h5>Experiences during previous projects</h5> <p>When an agile team has worked together in the same setting before, they probably have already experience an ideal sprint length. This team might want to use this experience in the new project as well. However, a pit fall in this situation is not taking all other mentioned aspects into account and just go blind on the experiences from the past.</p> <blockquote> <p><em>The more experiences with iteration length in similar situations the likelier a corresponding iteration length would be.</em></p></blockquote> <h4>Conclusion</h4> <p>There is no ideal iteration length that is applicable to all projects. All above mentioned aspects, your personal experience and probably a lot more will influence your decision about the iteration length in your project.</p> <p>I would suggest that you take some time at the project start to make the correct decision for your project. If this decision appears to be unworkable, don’t hesitate to come back on it after a couple of iterations.</p> Christo Martenshttp://www.blogger.com/profile/05488782784811298877noreply@blogger.com0tag:blogger.com,1999:blog-4579032008993018310.post-53002226805685935842015-06-16T16:32:00.000+02:002020-11-16T14:24:27.717+01:00The Bicycle Game<p>In one of my projects I developed a retrospective technique that is the combination several other techniques. This technique I called the ‘bicycle game’ because of the result: a nice bicycle. Do you want to know, how this bicycle game works?</p> <a name='more'></a> <h4>The game</h4> <p>This game has two main goals:</p> <ol> <li>To let the participants think not only from their own perspective but also from an external perspective <li>To let the participants do a deep dive in finding the real cause of a problem</li></ol> <h5>Timing</h5> <p>The game can be finished in about 60 minutes.</p> <h5>Materials</h5> <p>The Bicycle game makes use of :</p> <ul> <li>Sticky notes (3 colors) and pens <li>Two pieces of paper (flip-over, brown paper)</li></ul> <h5>Instructions</h5> <h6>Preparation</h6> <p>The agile coach prepares the game by identifying some (6 to 8)characteristics, that he wants the team’s feedback on. This might well be the shared team values that the team has defined during project start.</p> <p>Prepare a spreadsheet (like Microsoft Excel), containing the criteria the number of participants and columns that calculate the minimum, maximum and average of the rates, and that plots these values in a circular graph.</p> <p><a href="http://lh3.googleusercontent.com/-E050ulfW6L0/VYBAQZzXX-I/AAAAAAAAAKs/-WcKYFCIgYQ/s1600-h/image%25255B19%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-MOeGrsDxAuA/VYBAQ2V1yJI/AAAAAAAAAK4/xKo6M0qbHQg/image_thumb%25255B9%25255D.png?imgmax=800" width="315" height="71"></a></p> <p><a href="http://lh3.googleusercontent.com/-QDKbn6sguYk/VYBARNx5kUI/AAAAAAAAALE/4R8OueMM5ac/s1600-h/image%25255B18%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-ZSlc8VIpEI8/VYBAR9CPbwI/AAAAAAAAALQ/W_d7YzUdNVs/image_thumb%25255B8%25255D.png?imgmax=800" width="317" height="234"></a></p> <p>Duplicate this worksheet, and be finally creative in combining both graphs into a nice bicycle showing the average circles as wheels.</p> <h6>Execution – Information gathering</h6> <p>Start the game by asking the team to stand up.</p> <ul> <li>The Agile Coach draws a star on a paper one ax per selected characteristic. <li>The Agile Coach asks each team member to rate his personal feeling regarding each characteristic on a scale of 0 to 5 <li>The Agile Coach draws a circle like curve that connects the maxima and minima <li>This will end in a <a href="http://www.disruptivelearning.de/2014/02/13/team-radar-retrospective-tips-tricks/" target="_blank">team radar</a>.</li></ul> <ul> <li>The Agile Coach draws the same star on the second paper one (ax per selected characteristic). <li>The Agile Coach asks each team member to rate the feeling of some one the team is cooperating with regarding each characteristic on a scale of 0 to 5 <li>The Agile Coach draws a circle like curve that connects the maxima and minima <li>This will end in a second <a href="http://www.disruptivelearning.de/2014/02/13/team-radar-retrospective-tips-tricks/" target="_blank">team radar</a>.</li></ul> <h6>Execution – Deep dive into causes</h6> <ul> <li>The Agile Coach shows the ideal bicycle, with almost round wheels to the team<br><a href="http://lh3.googleusercontent.com/-a7pQOdJ58M4/VYBASSEc2UI/AAAAAAAAAKM/KIJd9EiBi70/s1600-h/image%25255B17%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-ZpE_eUrWvQs/VYBASy1DbEI/AAAAAAAAAKU/WH3kVSYsr6k/image_thumb%25255B7%25255D.png?imgmax=800" width="340" height="180"></a> <li>The Agile Coach shows the team created bicycle, like the one below<br><a href="http://lh3.googleusercontent.com/-7X-PV3_b4OA/VYBATj5KfdI/AAAAAAAAAKY/ggwSAviDEpg/s1600-h/image%25255B13%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh3.googleusercontent.com/-XvKJhlVKlBs/VYBAT1TXjzI/AAAAAAAAAKg/5Rqji78u-DY/image_thumb%25255B5%25255D.png?imgmax=800" width="339" height="184"></a> <li>The Agile Coach asks the team to write down for themselves the causes of this so unpleasant riding bicycle on orange sticky notes <li>The team sticks the notes on the related axis of both team radar <li>The team members discuss and group their notes <li>The Agile Coach asks the to write down the basic causes on yellow notes <li>The Agile Coach asks the to write down a proposed solution on green notes <li>The team sticks the notes on the related axis of both team radar <li>The team members discuss and group their notes</li></ul> <p>Note: Other colors will fit as well. </p> <h6>Execution – pick actions</h6> <p>The team members eventually decide on the best actions to take in the next sprint.</p> <h5>Learning points</h5> <p>Of course the learning points of this game depends on the characteristics that are discussed. However, a very nice thing is that the participants look to their project form out an outside in perspective and that the participants have experienced not to stop thinking when they have found a cause for a problem as there might be a bigger cause as well.</p> Christo Martenshttp://www.blogger.com/profile/05488782784811298877noreply@blogger.com0tag:blogger.com,1999:blog-4579032008993018310.post-35023483001109136402015-02-25T16:06:00.000+01:002015-03-13T16:29:05.316+01:00Enthuse the team in retrospectives during the entire project<p>A couple of years ago, I did an agile project with a lot of iterations. At the end of each iteration we held a retrospective. All of these retrospectives had the same agenda and each agenda item was implemented the same way over and over again. Though we found aspects to improve every retrospective, it became a weekly grind. Starting an new project with over 40 sprints I was questioning myself: How can those retrospectives stay interesting for the team, even after dozens of sprints?</p> <a name='more'></a> <p>The goal of a retrospective is to learn from the last iteration. This is usually done by looking back and by defining some points of improvement for the next iteration. A very basic technique is letting the team telling each other what went well and what could be improved. However when the team does this every week – our sprints had a length of just one week – for a longer period of time, it can become very boring. </p> <h4>Retrospective techniques</h4> <p>Fortunately, there are some websites that contain all kind of retrospective techniques (see <a href="#Sources">below</a>). When I started this project, I just tried one of these techniques: the happiness diagram. The team only had experienced the basic form of retrospective and was enthusiastic about this way of doing the retrospective. It decided to want continue this technique, which eventually resulted in the next happiness graph.</p> <p><a href="http://lh6.ggpht.com/-q6B8axEG690/VO37wybdA-I/AAAAAAAAAJA/B3n4dqbIAmk/s1600-h/image%25255B3%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: block; float: none; border-top-width: 0px; border-bottom-width: 0px; margin-left: auto; border-left-width: 0px; margin-right: auto; padding-top: 0px" title="image" border="0" alt="image" src="http://lh4.ggpht.com/-klr_xvCZNIQ/VO37xHo6aTI/AAAAAAAAAJI/cG24WskOEXQ/image_thumb%25255B1%25255D.png?imgmax=800" width="348" height="213"></a></p> <p>Knowing that even though the team liked this technique it would bore them, I decided to introduce a new technique the next sprint. The was surprised that another techniques (next to the happiness diagram) was used in that retrospective to which they participate enthusiastically. </p> <p>As I kept changing the techniques each retrospective the team was wondering which technique would be used in the upcoming retro. They even tried to cheat by looking in he project repository. </p> <p>During the project I used over 20 different techniques. I choose a technique based on my observations during the sprint. I develop a new technique: <a href="http://christomartens.wordpress.com/2014/12/08/the-tick-tack-boom-game/" target="_blank">the tick tack boom game</a>. Sometimes I <a href="http://lh6.ggpht.com/-7T5IIz44L90/VO3xOJtQORI/AAAAAAAAAIs/eCwD1yvtL-M/s1600-h/RHEV%252520-%252520Sprint%25252009%252520-%252520%2525206%252520thinking%252520hats%252520Retrospective%25255B4%25255D.jpg"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="RHEV - Sprint 09 - 6 thinking hats Retrospective" border="0" alt="RHEV - Sprint 09 - 6 thinking hats Retrospective" align="left" src="http://lh4.ggpht.com/-PZYKWp7c3nE/VO3xOkHA4cI/AAAAAAAAAI0/-awr-oQxXXU/RHEV%252520-%252520Sprint%25252009%252520-%252520%2525206%252520thinking%252520hats%252520Retrospective_thumb%25255B1%25255D.jpg?imgmax=800" width="167" height="102"></a>needed to take some attributes from home, like the colorful hats for the 6 thinking hats retro, or I used the traditional instruments like a piece of paper, sticky notes and a lot of pens. But every retro invited the team to participate, have fun, bring their ideas, concerns and benefits and have an open discussion. </p> <h4>Conclusion</h4> <p>A team likes a continuous change of the retrospective techniques. They told me that these changes forced them to look to our project for a different perspective every sprint. This brought them interesting new ideas. It makes them actively participate in this important agile meeting. And most important, the team kept improving over and over again.</p> <h4 name="Sources">Sources</h4> <p name="Sources">If you became inspired:.</p> <table border="0" cellspacing="0" cellpadding="2" width="400"> <tbody> <tr> <td valign="top" align="right">[1]</td> <td valign="top"><a title="http://www.funretrospectives.com" href="http://www.funretrospectives.com">http://www.funretrospectives.com</a></td></tr> <tr> <td valign="top" align="right">[2]</td> <td valign="top" ?><a title="http://www.plans-for-retrospectives.com" href="http://www.plans-for-retrospectives.com">http://www.plans-for-retrospectives.com</a></td></tr> <tr> <td valign="top" align="right">[3]</td> <td valign="top"><a title="http://www.retrospectivewiki.org" href="http://www.retrospectivewiki.org">http://www.retrospectivewiki.org</a></td></tr> <tr> <td valign="top" align="right">[4]</td> <td valign="top"><a title="http://tastycupcakes.org" href="http://tastycupcakes.org">http://tastycupcakes.org</a></td></tr> <tr> <td valign="top" align="right">[5]</td> <td valign="top"><a title="http://www.disruptivelearning.de" href="http://www.disruptivelearning.de">http://www.disruptivelearning.de</a></td></tr></tbody></table> Christo Martenshttp://www.blogger.com/profile/05488782784811298877noreply@blogger.com0tag:blogger.com,1999:blog-4579032008993018310.post-54231934403900056482015-01-12T09:13:00.001+01:002015-02-19T13:41:56.407+01:00Schizophrenia in agile projects<p>In quite a number of projects the project manager is asked to play the role of Scrum master or agile coach as well. These roles have a different project goal and point of view. Can fulfilling both roles lead to schizophrenia?</p> <a name='more'></a> <p>In my previous <a href="http://agilepmandcoaching.blogspot.nl/2014/11/project-management-in-agile-projects.html" target="_blank">blog on ‘Management in agile projects’</a> I have described the three management roles Project Manager, Product Owner and Scrum Master and how they could coexist. In this post I will show you why team members could think that a project manager that also is the Scrum Master is suffering from schizophrenia.</p> <p>According to <a href="http://en.wikipedia.org/wiki/Schizophrenia" target="_blank">Wikipedia</a></p> <blockquote> <p><em>“Schizophrenia is a mental disorder often characterized by abnormal social behavior and failure to recognize what is real. Common symptoms include false beliefs, unclear or confused thinking, auditory hallucinations, reduced social engagement and emotional expression, and inactivity. Diagnosis is based on observed behavior and the person's reported experiences.”</em></p></blockquote> <p>Fortunately, someone playing both roles isn’t schizophrenic, so not all characteristics will come true.</p> <h4>Observation</h4> <p>First of all, the the diagnosis needs to be based on observed behavior and reported experiences. The ones who can do the best observation are members of the development team (Product Owner, developers, testers, analysts etc.). They work in close collaboration with our victim on a day by day basis. What behavior can they observe?</p> <p>Suppose the project has just started based on some kind of calculation. As a project manager our victim is very result driven. He has made planning and likes the team to follow the plan as close as possible. So the first thing he does is telling the team what to do first, e.g. realize a specific story. However as the Scrum Master of the team our victim want the product owner to set priorities and let him or her pick the stories with the highest priority in the sprint, and finally let the team decide in the sprint planning, how much of these stories they think they can get to done. Most likely, these stories are not the same as the stories in the planning and the planned velocity is not the velocity the team thinks it can make. Because to the Scrum Master the most important thing is that the team and the Product Owner are feeling comfortable with the stories, the victim would say something like “If this is what you think is good, please do so”. Our victim shows both strongly directive as very laid back behavior in a short period of time; observers could call it unclear thinking.</p> <p>The team learned from the reaction of the victim as project manager, so they subconsciously decided to follow the plan. They took some stories in the sprint they thought that would be important and they neglected the priorities of the product owner. As the project manager’s planning was quite ambitious, they even worked some overtime for free. Making the project manager in the victim very happy. However, during the retrospective it appears that the product owner didn’t like this kind of proactive behavior. The Scrum Master in our victim now had to act. He had to teach the team to follow the agile rules by having the Product Owner in the driver seat and realizing in a sustainable pace. As this appeared to be an old habit of the team members, the Scrum Master had a lot of work in coaching the team towards agility, without being directive. The team that just get used to the project manager in our victim, now observes a non directive very facilitating coach. They observe some kind of false believes in our victim.</p> <p>As a Scrum Master our victim is the facilitator of the sprint meetings, like the Retrospective. In one the Retrospectives a team member noticed that the team is behind schedule and that the cause is laying in lack of resources. This team member immediately asks our victim to take the appropriate measures. Our victim decides not to react during the retrospective because he is in this meeting as the Scrum Master and not as the project manager. The team member again observes some unexpected reaction by our victim.</p> <p>As the project continues and the product backlog increases, our victim will look into his planning and his budgets. He will notice that the budget and time he will need to finish the project based on the ETC and the actual work completed, will exceed his project budget or the deadlines. Immediately, he will do an impact analysis, check his risk log and if necessary write an exception report for the project board. He also will run to the the team members for corrective measures by telling them that they need to do such or so. On the other hand the Scrum Master is very confident how it goes. The team is working in an agile way and is delivering stories with a constant velocity. He sees that the team is improving and as the Product Owner is prioritizing well, only stories with little business value will remain.To our victim live is beautiful and relaxed again just a couple of minutes after he was in a hurry because everything was going wrong. Strange unclear behavior, this can be called.</p> <p>These situations make clear that someone playing both the project managers and the Scrum Masters role can ran in situations that require a total different approach that can be be experienced as schizophrenic behavior.</p> <h4>How to prevent being pointed as schizophrenic?</h4> <p>First try to prevent that you run in such kind of situations. The easiest way is not fulfilling both roles in the same project. If you manage to do so, it is very clear to the team which role you fulfill and what they can expect from you.</p> <p>However, is quite a lot of agile projects the project manager is also asked to be the Scrum Master. There may be many causes for this, like the combination of those two roles make one FTE on the project or you perfectly fit both roles because of your experience as coach and project manager. Either way, you ran in this situation and you don’t want to depicted as schizophrenic. What should you do?</p> <ul> <li>At the project start tell the team that you will fulfill both roles and that sometimes these roles will conflict with each other.</li> <li>When you run in a potential schizophrenic situation, stay calm and decide what role you should play at that moment. Base this decision on what is the best for the team and the progress. Give the team your opinion in words like “As a Scrum Master I would …” or “As a project manager I would …”. Your team will notice your struggle and will also think about what you didn’t say.</li></ul> <p>Being open is the most effective way of preventing to be seen as Schizophrenic, supposing you aren’t.</p> Christo Martenshttp://www.blogger.com/profile/05488782784811298877noreply@blogger.com0tag:blogger.com,1999:blog-4579032008993018310.post-40367955155318697962014-12-05T10:24:00.001+01:002020-11-16T14:24:54.166+01:00The Tick Tack Boom game<p>Inspired by the game known in the Netherlands as ‘Tik Tak Boem’ or in English ‘Pass the Bomb’ I developed a retrospective game. Do you want to know what it looks like?</p> <a name='more'></a> <h4>The game</h4> <p>The people participating in the game are forced to think and speak fast which prevents them to react politically correct.</p> <h5>Timing</h5> <p>One round in the game takes a couple of minutes. Taking the explanation time and the number of rounds into account the game can be finished in 30 to 60 minutes.</p> <h5>Materials</h5> <p>The Tick Tack Boom game makes use of the physical game ‘Pass the Bomb’. It uses the next parts of this game:</p> <ul> <li>The bomb (mandatory) <li>A special dice and cards (optional)</li></ul> <h5>Instructions</h5> <h6>Preparation</h6> <p>The agile coach prepares the game by writing down some important questions. These questions can vary depending on the coach’s goal with the game. </p> <h6>Execution</h6> <p>Start the game by asking the team to stand in a circle.</p> <ul> <li>The agile coach asks one of the prepared questions and he gives the activated bomb to one of the participants <li>The one with the bomb answers the question [Note: duplicate answers are rejected] <li>On a correct answer he or she throws the bomb to the one who is next to him/her (clockwise) <li>If he bomb goes off in your hands, you loose. You also loose if the bomb is still in the air on its way to the next person (unless catcher dropped it). <li>As a facilitator the coach could write down the answers for later use. <li>The agile coach asks the next question </li></ul> <p>Reward the one who has lost the round or has lost the most during the entire game.</p> <p>When you want to make the game more complex, but slower, you can use the dice and the cards. The team now needs to think harder. You can alternate the game by sometimes using the cards and sometime not. This could keep the participants alert.</p> <h5>Learning points</h5> <p>Of course the learning points of this game depends on the questions that are asked. However, a very nice thing is that the participants tell each other things they usually wouldn’t do. They don’t have a lot of time to answer, so they give the answer that is on top of mind. This results in interesting points of view, that otherwise could have been covered by political correctness. In this way the game supports openness between the participants that could eventually also improve openness within the team during the project.</p> <h4>How to use</h4> <h5>Retrospective</h5> <p>The Tick Tack Boom game can be used in combination with a lot of retrospective techniques. The game can be in each retrospective stage (set the stage, gather data, generate insights, take action and close). For instance, I have combined this game with the next techniques with nice results.</p> <ul> <li><a href="http://www.funretrospectives.com/one-word/" target="_blank">One Word</a> (1 or 2 rounds) <li><a href="http://www.plans-for-retrospectives.com/?id=54" target="_blank">Story Oscars</a> (3 questions) <li><a href="http://www.plans-for-retrospectives.com/?id=20" target="_blank">Perfection Game</a> (2 or 3 rounds) <li><a href="http://www.plans-for-retrospectives.com/?id=61" target="_blank">Chaos cocktail Party</a> (1 or 2 rounds) <li><a href="http://www.plans-for-retrospectives.com/?id=60" target="_blank">Aha!</a> (2 or 3 rounds)</li></ul> <p>Based on the answers the coach decides how many rounds are sufficient.</p> <h5></h5> <h5></h5> <h5>Teaching agile</h5> <p>It can also be used to check what your team knows about agile software development. In that case you can prepare some questions and use the cards to make it more difficult.</p> <h4> <hr> The physical game</h4> <p>Information regarding the game can be found on the websites of the manufactures</p> <ul> <li>English<br><a title="Pass the Bomb" href="http://gibsonsgames.co.uk/pass-the-bomb/" target="_blank"><img alt="Pass the Bomb" src="http://gibsonsgames.co.uk/pass-the-bomb/wp-content/themes/pass-the-bomb/images/header-img.jpg" width="149" height="92"></a> <li>Dutch<br><a title="Tik Tak Boem" href="http://www.goliathgames.nl/product/tik-tak-boem/" target="_blank"><img src="http://www.goliathgames.nl/wp-content/uploads/sites/5/2014/08/70440-Tik-Tak-Boem-L-P1-700x500.png" width="124" height="89"></a></li></ul> Christo Martenshttp://www.blogger.com/profile/05488782784811298877noreply@blogger.com0tag:blogger.com,1999:blog-4579032008993018310.post-81525778646186116592014-11-28T17:02:00.001+01:002021-02-09T10:07:12.259+01:00Doing law and regulation development the Agile way<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh3NNfjIuIJbkOF4KWP25oapUuib87B4pjOkrym76EPyglzomW_YEhdmtrxtwyusrOeCfmP4J2OoCbEpq_p75GkTjwG4buPn8bUelf6cAyRQMR5TC7Ju-ZVQo6QExfub-51dyFLXEEayIuK/s640/Wetten+schrijven.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="Writing laws" border="0" data-original-height="409" data-original-width="640" height="127" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh3NNfjIuIJbkOF4KWP25oapUuib87B4pjOkrym76EPyglzomW_YEhdmtrxtwyusrOeCfmP4J2OoCbEpq_p75GkTjwG4buPn8bUelf6cAyRQMR5TC7Ju-ZVQo6QExfub-51dyFLXEEayIuK/w200-h127/Wetten+schrijven.jpg" title="Writing laws" width="200" /></a></div>Recently I had a conversation with the Senior User of one of my Scrum projects, who also appeared to be a lawyer. We were talking about why my Scrum project was doing so well. I explained her why the agile way of working we used in our project, is one of the success factors. Her enthusiasm about the approach made her phrase the next question: Can we use this agile approach in development of new laws and regulations?<br /><p></p> <a name='more'></a> <p>This is an interesting question. Though I don’t know anything about creating laws and regulation, I have tried to imagine what such project would look like when executed in an agile way.</p> <h3></h3> <h4>Project Roles</h4> <p>In agile projects at least three roles are identified: the product owner, the development team and the agile coach. </p> <ul> <li>The <b>product owner</b> is in charge of the scope and he will be prioritizing the product backlog. Though the minister or secretary of state is responsible for the law creation, a lower officer of the ministry can perform this role, as long as he has sufficient mandate and knowledge </li><li>As the <b>agile coach</b> is guiding the team on their agile road no matter what project, there would be no difference between an agile coach in a software development project and a law creation project. It is more important that the coach can teach the team than that he is familiar with the matter, i.c. the law process. </li><li>The <b>development team</b> is responsible for describing the new law. For that reason, it has to be populated with team members that know everything about creating a law, like legal officers and assistants. </li></ul> <h4>Product backlog</h4> <p>The basis of every agile project is the product backlog, a prioritized features list. It contains short descriptions of all functionality desired in the product. For a new law this could be a list of all articles of that law with a short description of the purpose of the article.</p> <p>At the project start the product owner should fill the product backlog with law articles and optionally special (exception) paragraphs. Per backlog item he describes the purpose. He also needs to prioritize these articles such that the articles with the most business value. By doing that he already has to think about the outline of the law which will certainly help him during the project.</p> <h4>Definition of Done</h4> <p>Both product Owner and development team need to know when backlog items are Done. This is described in the Definition of Done (DoD). </p> <p>Where in software development it could contain sentences like ‘meets (performance) requirements’, ‘has been tested’, ‘has been installed in environment X’ and ‘has been documented), the rules in the DoD for law are probably more like ‘contains at least 1 paragraph’, ‘lawyer X thinks it is very clear’ and ‘exceptions are described’. Of course, the new law needs to be approved by the parliament. Because the is approval activity is outside the scope op the development team, it may not be part of the DoD. The product owner however should be well informed about the amendments the parliament like the minister to be processed. </p> <p>When the Definition of Done is clear, the team can start developing the law iteratively.</p> <h4>Iteration and regular activities</h4> <p>As in regular agile software development projects also law development projects should be executed in small iterations. I would suggest to keep them the same length, so 1 to 4 weeks. These iteration should start with a planning, end with a review and retrospective and have a daily stand up.</p> <p>The iteration planning, retrospective and daily standup can be quite similar to software development projects. A more interesting question would be, what to show during the review. As most product backlog item intend to realize an new or adjusted article or paragraph of the law, their texts would be the thing to show and review. To me this seems quite boring. But when you find a way to involve the stakeholders, subject matter experts and product owner in this review vividly, these reviews might also work in a law creation project.</p> <h4>Benefits of this agile approach</h4> <p>As someone who isn’t familiar with law and regulations, I notice that judges often have to interpret laws, when they pronounce the verdict in court. If the law had been designed based on user stories or like wise, it would be more accurate to the judges. By developing in an agile way, it would also become much earlier clear to the development team that some parts are missing or multi interpretable. Eventually the created (or adjusted) law would get a higher quality and more suitable for a daily use.</p> <p>So, I do think that laws can benefit from a agile development approach.</p> Christo Martenshttp://www.blogger.com/profile/05488782784811298877noreply@blogger.com0tag:blogger.com,1999:blog-4579032008993018310.post-21051393200913726012014-11-19T22:50:00.003+01:002015-01-12T09:18:04.622+01:00Management in agile projects<span style="mso-ansi-language: en-gb; mso-fareast-language: en-ca" lang="EN-GB">In Scrum there are two management roles: the Scrum Master and the Product Owner. In other methodologies the project manager role is also known. How do and can they coexist?</span><br> <a name='more'></a> <div class="MsoNormal"><span style="mso-ansi-language: en-gb; mso-fareast-language: en-ca" lang="EN-GB"></span></div> <div class="MsoNormal"><span style="mso-ansi-language: en-gb; mso-fareast-language: en-ca" lang="EN-GB">The picture below describes the influence on the project of each management role. </span></div> <table style="text-align: center; width: 2px; margin-left: auto; margin-right: auto" class="tr-caption-container" cellspacing="0" cellpadding="0" align="center"> <tbody> <tr> <td style="text-align: center"><a href="http://lh5.ggpht.com/-mAUI59MoS0s/VHLnjzQf-MI/AAAAAAAAAHU/i5RPRfam_gY/s1600-h/image%25255B16%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="http://lh6.ggpht.com/-qZZUNdd1Mag/VHLnkYwCyrI/AAAAAAAAAHY/AtUGzFTsPZY/image_thumb%25255B6%25255D.png?imgmax=800" width="425" height="244"></a></td></tr> <tr> <td style="text-align: center" class="tr-caption">Manager lives at the boundary</td></tr></tbody></table> <h5><span lang="EN-US">Scrum Master</span></h5> <div class="MsoNormal"><span style="mso-ansi-language: en-gb; mso-fareast-language: en-ca" lang="EN-GB">The Scrum Master informs the outside world on the agile way of working of the team. Within the development team he encourages open communication. At the iteration end the Scrum Master organizes a retrospective to let the team reflect themselves. The Scrum Master takes impediments away in order to keep the focus on a timely delivery of business value. In this way he improves the team motivation.</span></div> <h5><span lang="EN-US">Product Owner</span></h5> <div class="MsoNormal"><span style="mso-ansi-language: en-gb; mso-fareast-language: en-ca" lang="EN-GB">The second management role in agile projects is the product owner. As a (delegated) sponsor he funds the project. He takes the necessary decisions for the project. When there is more than one sponsor, the product owner is mandated by the other sponsors to make the decisions. He is responsible for the prioritizing the backlog based on the business value of each individual backlog item. He also decides when to go live and when to end the project.</span><span lang="EN-GB"> </span><span lang="EN-US">He safeguards the business case by weighing the business value against the realization costs of still to be realized backlog items.</span></div> <h5><span style="mso-bookmark: _toc375311810"><span lang="EN-US">Project Manager</span></span></h5> <div class="MsoNormal"><span style="mso-ansi-language: en-gb; mso-fareast-language: en-ca" lang="EN-GB">The general task of the project manager is to inform the outside world, like the project board, about the progress and the achievements of the project and to give direction to the team. The latter however doesn’t comply with the agile way of working.</span></div> <h5>Coexistence</h5> <div class="MsoNormal"><span style="mso-ansi-language: en-gb; mso-fareast-language: en-ca" lang="EN-GB">In agile projects the management supports the team rather than being directive. So, if the project manager want to coexist with the other management roles, he should act slightly different. On the other hand, they should be willing to </span>cede some of the responsibilities which Scrum assigns to the Scrum Master and Product Owner roles.</div> <div class="MsoNormal"></div> <ul> <li> <div class="MsoNormal">The <strong>project manager</strong> keeps the responsibility for the project budget. He also needs to take care of the interruptions from outside of the project trying to prevent the negative influence of these interruptions to the development team. Within the development team he aligns the goal perception of the team members and he takes care of their skill development, but he may not give directions to the team anymore.</div></li> <li> <div class="MsoNormal">The <strong>Product Owner</strong> will be in charge of the project scope. He prioritizes the backlog and decides about necessary changes, unless these changes exceed the project mandate. In this way he has still influence on the business case without being responsible for it.</div></li> <li> <div class="MsoNormal"><span style="mso-ansi-language: en-gb; mso-fareast-language: en-ca" lang="EN-GB">The<strong> Scrum Master</strong> is mainly seen as an agile coach. He still takes care of impediments, but when they are outside his circle of influence the project manager takes it over.</span></div></li></ul> <div class="MsoNormal"><span style="mso-ansi-language: en-gb; mso-fareast-language: en-ca" lang="EN-GB">Those three roles can indeed coexist. They can even benefit from each other when they can get a higher focus on their main goal.</span></div> Christo Martenshttp://www.blogger.com/profile/05488782784811298877noreply@blogger.com0