scrum – Pagina 2

Category Archives: Scrum

09 Jan 2018

Retrospectives: tool for distributed retrospectives

Little gem for distributed retrospectives!
In recent years, I have worked with distributed teams occasionally. In an early team an eager colleague, Stefan Kemp, created an interesting responsive web application to support retrospectives in this team setup. That is already 5 years ago. Up until this week I have been using his app for different customers and teams. Let me walk you through it and share my enthusiasm.

Step 1: Getting organized
As a first-timer you create your account and you can register a new team straight away, go here: retrospective.rhea.infosupport.net. Once you are in, you can invite your fellow team members via email. Then you can plan your next retro and instruct everyone that the retro app is going to be used – and more importantly – is already waiting for the first items! There are three types of input awaiting: positive items, improvement topics and flowers to thank team members or other involved teams or persons.

Step 2: The retro
Usually the Scrum Master drives the retro, but in theory anyone can guide the team through the session. It works best if you have shared audio and a shared screen. In that case, everyone can see what is happening on the same screen . Depending on your organization’s tool-setup these can be facilitated by different technical solutions (e.g.: Skype, Polycom, Communicator or Hangout).

Before you start it is good to check if everyone was able to provide the input before the session. If not, you can take a couple of minutes to do so. Another approach would be to let people do it on the spot when it is their turn. When started, one person at a time explains his or her inputs and places these onto the shared canvas. In case people have prepared the same topics, these can be grouped together. If any item is no longer valid it can be deleted. After everyone has finished, it is time to vote and give the last sprint a personal rating. The voting and rating can be done on the screen or by personal device (tablet, phone or pc). For the mobile devices an easy access a QR-code is presented so everyone can get to the mobile version available in an instant.

The voting and rating result in an ordered list of improvement topics to discuss. Each topic can be given concrete actions and remarks. The actions can have a responsible team member assigned to it, or the team as a whole.

Step 3: Wrap up
Once you have discussed enough topics, or the time is up, you can finish the retro. The Scrum Master can send everyone the outcomes of the retro, so actions can be taken into the next sprint or picked up immediately. In the next retro you can start by looking back at the open action items and check what the results are.

Conclusion

The supported flow and functionality is pretty much that of a default retro with everyone available in the same room. The app itself is very easy to understand, usually after one first retro everyone is fully up to speed to use it to its maximum the next time. Even if you don’t have a distributed team the tool can be used. Either as the default modus operandi or as a change of retro scenery. Thanks Stefan!

Top features include:
• A very swift set up for your team, including invitations
• Adding your personal input throughout the sprint
• Easy format during the retro, including grouping and voting to reduce the numbers of topics
• Emails to remind your team of upcoming retro’s and the outcomes of them
• Some nice charts and trends related to team characteristics

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,scrum Posted on: 9 January 2018

11 Dec 2017

Retrospectives: communication & personalities

Some time ago, I experimented with some team retros to start discussion and exploration on our communication and the team’s personalities. After a few tries I came up with this small format. It helped me and my teams getting a swift feeling on each other’s do’s & don’ts and to create a general team vibe. You can use this format either at a new team formation or whenever you are looking for an alternative retro.

Invite & preparation
This format starts with an explicit invite and personal preparation. Thinking on your individual story and using the results to formulate your ideas before the session gives people a head start and saves time during the session. In case new topics do come up, you can always still on-board them on the fly. For the Scrum Master this phase means collecting and preparing all the inputs and making sure they are available during the session.

The actual retro
All team members do their personal pitch with the help of their preparation and a personal page provided by the Scrum Master. Sometimes teams are a bit shy to start. So it can be a good idea as a facilitator to start by setting the example and presenting your own slide. Usually other team members will come up with questions and then the session is kick started easily.

Team overview
After everybody has had his turn, you can present the team overview. The more diverse the better. A picture can tell a story but the value for me is in the interaction and flow that is created during the retro. Besides, most teams like to see their team picture! Based on the kind of tests you have selected for your team, you can get different options for visualization of course. There is no need for expensive material or assessment centers. Start with the options that are easy to use and for free (like the ones I have used).

Note: in the end it does not really matter which tests you use. This approach as such helps people thinking and talking about themselves. Although the graphs merely act as conversation starters, they do tell you a thing or two about the team……

Have fun!
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,scrum Posted on: 11 December 2017

01 Sep 2017

Visualization helps Agile Teams & Organizations

Transparency is one of the corner stones of great Agile teams and organizations. If that is the case, isn’t it strange that so many teams have little outwards visualizations? Not only teams benefit from visualization, but also management and other stakeholders could gain direct insights from the information presented. In this blog, I will discuss visualization from different perspectives using my own checklist as a starting point (see at the bottom of this blog). At the end, I will share a few pointers to get you started.

The eight examples on my checklist are a nice start. Depending on your team or department characteristics, you can probably add a dozen others. Some at least as important as the ones on the list. However, the true value for me lies in the dialogues and questions that arise from them instead of the – more fundamental – discussion on which items should or should not be on the list.

Team perspective
Let’s start with the team perspective. The first reaction and question that usually pops up is: for whom are we visualizing? Unarguably, it should be for ourselves and our stakeholders. So, if we do it for ourselves, we need to have information radiating that is important and useful for us. In my opinion, all topics on the checklist should matter to any given team. If not, there is a chance something is off in the basic way the team is functioning and/or supported by its organization. Do it, pick one topic and argue that it is not important for a healthy routine of your team.

The second reaction from teams can come from two directions: “we don’t have that information” or “it takes too much time to gather it”. Both arguments are excellent starting points for valuable discussions – during retro’s or just over coffee. Not having the information means that your team is flying in the dark. Either the product or the company’s road map is not clear or perhaps the feedback loop for continuous improvements is not implemented. If collecting these basic team drivers takes too much time, chances are that tooling is not in place or not used correctly. The reactions mentioned in this paragraph are indicators that the Way of Working can be improved.

Management perspective
Let us shift to the managerial perspective. In more Agile oriented organizations this perspective often leads to a different reaction compared to the ones above. “My teams are self-organizing, self-managing or self-supporting, so they decide what is shown and needed.” Wrong! As long as managers are responsible for their performance – either hierarchical or via a more servant-leadership – it is their job to have an interest in these subjects. If not, they’ll have a tough time explaining what added value they have for their teams and thus their organization. For example, how can a team manager not want to see Impediments or improvements made by his or her teams? In addition, teams often need directions and coaching on organizational goals and drivers. Outward visualization helps the process of aligning the organizational goals and the Way of Working of the teams.

In practice, it can be challenging to implement and decide on the most useful visualizations for your teams or department. Remember it is good to try things and ask around who is interested in what information. Or as a manager, discuss with your teams what the goal and improvements are from an organizational point of view. If done right, the information not only benefits the teams, it is also a source of information that could substitute numeral status meetings.

Stakeholder perspective
The third and last perspective is that of the stakeholders. Top priorities for stakeholders usually contain the question: “When is this or that feature finished?” By showing this information crystal clear in the team area, the team provides the stakeholders with direct insight. Moreover, it helps by building confidence and making the team predictable for its environment. Perhaps the expected date example is a bit simplified. How about this one: create a good Story map of the current product (iteration) and put it in a visible place in the area. Make sure you add significant release dates, in case you don’t go to production in every sprint yet. Now, the timeline has its own functional context which makes clear what the stakeholders can expect. For teams, it is good to adjust to the stakeholder’s needs. Thus, especially as a Product Owner you should invest in what the stakeholders would like to see and hear from the team. Also, be confident to use visualization and communication forms you have seen working before.

A few pointers to get started
Responsibility: who’s responsible for visualization? When teams just start, most of the times it is the Scrum Master who begins with Burn down charts and Impediment boards followed by other more Scrum – or process – related information. In my opinion, it should be a Scrum team effort. In other words, everybody – also the Product Owner – is using the team area to show road maps, examples or key metrics. This will stimulate the philosophy that if it is important for the team, we put it up there. Anyone can decide or try to use some new metric or insight. This does not mean that other stakeholders cannot let the team know what they would like to see.

Gemba walks: one practice that provides insights to all stakeholders is doing Gemba walks across multiple team areas. Don’t ask how things are going straight away. Instead, look around and see what the information presented is telling you. I have used this technique also with colleagues visiting other teams. Besides entertaining it is an easy mechanism to share practices and bring teams a little closer. A Gemba walk might be a catalyst for explorations on visualization benefits for teams, managers and stakeholders.

How to show: I did not elaborate on the form in which information is shown. That is on purpose. Depending on the team, tools and context, you’ll get different outcomes. The fact that I am not a great sketch artist results in more print outs for my teams. In companies with big screens available in team areas you can have as much metrics and info on the screen as you would like. In some companies on the other hand, there is a strict clean desk policy and very little information is allowed to radiate from team areas.

Conclusion

The discussions and feedback from teams and stakeholders can be as valuable as the visualizations themselves. So, make sure you are aware of their thoughts and needs before mounting all kinds of information to the walls. Depending on your role you can initiate the dialogue with or within your teams in diverse ways. Use the checklist, the Gemba walk or any another conversion-starter in your team or department to explore the benefits of visualization. I am curious to hear your experiences and/or remarks. The discussion and feedback from teams and stakeholders can be just as valuable as the visualizations themselves. So make sure you have these before you start mounting all kinds of information to the walls, or demanding this as management.

Download the one-pager: Visualization helps Teams and Organizations

Cheers,
– Sjors Meekels

References

There is a lot of information out there, so I added just a few examples to get you going:
[1] www.infoq.com: Visualize Agile https://www.infoq.com/visualize-big-picture-agile
[2] Ben Linders: Visualizations https://www.benlinders.com/visualization-team-deliver-value/
[3] www.thoughtworks.com: Story-mapping https://www.thoughtworks.com/story-mapping
[4] Toolbox for the Agile Coach – 96 Visualization examples, Jimmy Janlén, 2015
[5] Coaching Agile Teams, Lyssa Adkins, 2010

Download blog as PDF

This blog is available here:

Filled Under: agile,agile projectmanagement,kanban,scrum Posted on: 1 September 2017

14 Apr 2017

Product Owners in DevOps: What dominates your Backlog, Urgent or Important matters?

Product Owners have a great responsibility in prioritizing the work on the Backlogs. Their role can hardly be underestimated. How about some support from the past? Decades ago Eisenhower made a quote on important and urgent matters. His idea has transferred into a matrix used to prioritize personal actions. Can Eisenhower’s priority matrix help Product Owners in prioritizing backlog items? I think so. In this post I will combine Eisenhower’s ideas with those of Agile product backlog management, and a little wild life.

Eisenhower’s matrix
In short, Eisenhower’s matrix focuses on four distinctive quadrants created by the two viewpoints – urgency and importance. The goal is to determine someone’s priorities [1][2].

Urgent matters: require immediate attention. If possible you should act on these matters now. Important matters: these relate to long term objectives and need constant focus. When combined this leads to the following overview and actions:

Now let’s transpose these quadrants to backlog management in an Agile environment. All work on the Backlog can be qualified according to Eisenhower’s quadrants. But what is the optimum setup for your Sprint Backlog? Is there any? Based on the model, I will discuss a set of situations which are all taken from projects and teams I have worked with over the years. In these situations, teams are working on Product Backlog Items that primarily originate from one of the quadrants. To make teams easily recognizable, they all have a different nickname which sticks out.

1. Orange Firefighters, brave and busy

If your teams are busy working on the urgent important issues or new work of this category is entered each running sprint, it seems like your devops-teams are firefighting. This is only a good thing when a) there is an actual fire and b) – more importantly – they can extinguish the fire. If this pattern is more the rule than the exception, changes are something is not OK. This could relate to your production environment, either the applications, the infra, people handling it, or all. Try to look for the root causes and fix those, via the regular process of course. Instead of focusing on optimizing the fire-hoses and firemen. Although your teams are working on the top priority work items, there are risks and down sights. For example, every Product Backlog item which is refined or taken in the sprint and pushed out by the orange firefighters, has been a waste of time. Moreover, the company’s short term future may get hurt if this situation occurs for too long a time.

PROS: working on top priority items, CONS: waste in preparation time, pressure within teams, ATTENTION: should not persist for long, focus on fixing root causes!

2. Blue Coyotes, opportunistic

Sometimes teams are working on urgent but not important issues sprint after sprint. These teams are the so-called coyotes. This scenario also raises an interesting question. Are those issues really urgent? If you and your team tend to say no, there should be a dialogue. Re-discuss these issues with your stakeholders and try to balance them out with your company’s important stories. In practice it is more convenient to work on topics that are urgent to our stakeholders now. However, don’t go for convenient, but invest in discussions and long-term goals.

Okay, so are you done when the answer is yes? Well, sorry, no. If this situation is continues for a long period of time, it could be a sign that you are understaffed. Not working on the important issues, could be a serious threat to business continuity on the long term. Perhaps you can consider to appoint a temporary team that can eliminate the ‘pile’ of urgent stuff, which is in the way of working on the important stories. However, one thing should be in place before you scale up: a clear vision on what is actually important. This may sound like a no-brainer, but more than a few Product Owners are struggling in identifying what is really contributing to the company’s future.

PROS: satisfying to stakeholders, CONS: not working on the long run, ATTENTION: are backlog items really that urgent or is there too much stuff in the way?

3. Green Tortoises, steady but a bit boring

The third scenario reflects the mindset of the tortoise. Namely, where the majority of the work directly relates to important backlog items. Good for you, you keep the company or department in business. However, you might be missing out on immediate revenues from low hanging fruit. Why not optimize your SEO rank now and then, or eliminate that bug 80% of your users are complaining about? These small improvements won’t harm the long-term objective and they do give you a change to help users, increase the short-term cash-flow and satisfy a few stakeholders along the way. Like their nickname, these projects or teams can be a bit boring and move slowly towards a certain ‘old age’ or goal. In their journey, they could lose the connection with the rest of the organization when results are not made visible in the meantime. Besides that, if these projects entail migration without new functionalities, also the teams can get bored. They may benefit from the diversion of small improvement stories.

PROS: working on the mission of the company, CONS: in long running projects stakeholders can get detached, ATTENTION: room for quick wins along the way?

4. Well… Black Dodo’s

If you have teams working on the black stuff, something is off. Perhaps you are way overstaffed, or backlog management is in utterly disorder. Avoid this situation at all costs. When nothing changes soon these teams will become extinct…

PROS: none, CONS: waste of time and energy for all, ATTENTION: immediate action required!

Balancing act, rhythm and focus

Do you feel like you are getting mixed signals now? You are right. This is the arena where great Product Owners can stand out of the mediocre crowd. If they are able to balance the Product Backlog with the stakeholders and find a rhythm together with their team(s) to ensure enough focus, you have a winning combination. Relevant questions to be answered are: Who is your most important stakeholder? And how are competing stakeholders managed? What is most important for the customer and the future of the company?

A predicable heartbeat helps the team and PO in delivering on regular intervals. Yet, it also promotes alignment in the rest of the organization. The characteristics play an profound role in the optimum heartbeat. For example, if you are part of a true DevOps team, you know ad-hoc work (important and urgent issues) will emerge and that is part of your sprint routine. In another case you might have a more component oriented team, building stuff for other teams.

If you only have one development team available, the balancing act of shifting priorities becomes more precarious. The team can feel comfortable working on multiple topics in one sprint and it is not forbidden to do so, as long as there is enough clarity and stories are really Done at sprint’s end. However, most teams benefit from focus during the sprint, so when possible, craft your Sprint goal on one or two categories only. You could for example spend one sprint on urgent matters and the next two or three on the important trajectory. In general, true orange stories are always executed asap. When multiple teams are involved you can have more flexibility and for example rotate duties between teams every few sprints.

Last thoughts

So, Eisenhower can help in identifying certain wanted or unwanted patterns in your current Product Backlog. What it cannot do is provide the ‘correct’ distribution. That task is still meant for the Product Owners and their teams. I am curious, what kind of wildlife represent your teams currently and how is your Backlog setup in terms of Eisenhower’s quadrants?

Cheers,
– Sjors Meekels

References

[1] Eisenhower: http://www.eisenhower.me/eisenhower-matrix
[2] Eisenhower: http://www.businessinsider.com/dwight-eisenhower…..
[3] Coyote: https://nl.wikipedia.org/wiki/Coyote
[4] Tortoise: https://en.wikipedia.org/wiki/Tortoise
[5] Dodo: https://en.wikipedia.org/wiki/Dodo

Download blog as PDF

This blog is available here:

Filled Under: agile,devops,scrum Posted on: 14 April 2017

14 Nov 2016

Must I Do This Now? In an Agile context

Over the years, I have worked with many teams within organizations moving from left to right in constant change. People from all places are targeting Engineers and other team members with ad-hoc questions or small assignments. Of course, in Agile environments Product Owners and Scrum Masters should be there to shield part or most of these interruptions. Yet, that is not always possible. The result is people who get distracted and are not confident about priorities. This is only a ‘big’ problem when there is more work to do than is possible timewise. So that is pretty much anywhere. Hence, we have to prioritize to keep ourselves and our teams focused. The mnemonic ‘Must I do this now’ can help you redefine your priorities.

Must I do this now?

There is a lot of power stored in this little sentence constructed out of 5 words. Let’s play a game and change the emphasis 5 times in a scenario where someone asks you to do something right now. See what happens to the meaning of the question and how it can help you redefine your priorities. In each case I’ll reflect on the way the question should be answered in an Agile context.

1. [MUST] I do this now?

Is the chore or question really necessary? People working in projects are used to MoSCoW [1]. I reuse that idea: if it is not a Must you probably should not do it. Often you immediately know if something is that important or just a nice thing to have.

In Agile: In using Scrum or Kanban, you can check the current Sprint Backlog or Work in Progress and verify that nothing in there is less important than the new chore at hand. In case you are doubting, the Product Owner should be there to help you decide. Do not hesitate to ask for clarity or advice.

2. Must [I] do this now?

During your day you might receive a lot of questions. For some people asking something is even second nature to them. Often easier than thinking or solving a problem by themselves. Well, your time is valuable as well. The next step is to rethink if you are indeed the best person – or the only person – that is capable of handling this request. Perhaps the requester or another colleague is equally equipped.

In Agile: Teams should be able to handle all the tasks and preferably all skills are shared and well distributed among the team members. At least there should be someone else – besides you – capable of responding to the request. If someone else is looking to pick up something new and he or she is capable you don’t need to interrupt your current task. This will help you to stay more focused.

3. Must I [DO] this now?

Before rushing into solving mode or chasing a problem, check out what the best modus operandi would be. What would solve the request? Sometimes no action is required at all. If the answer is the latter, there is no need to use the other questions. It is for this reason that this question is sometimes promoted to the top. In this blog, I stick to the order of the words for simplicity.

In Agile: In Scrum all user stories that are part of a Sprint must be ready and crystal clear. That means that the outcome itself and the way to achieve the outcome are also clear. If the “Do” part of a chore is not clear than the first step would be to get that clarified by the Product Owner or other stakeholders before adding it to sprint. Scrum Masters should learn teams to make stories as clear as possible and should check the clarity of the “Do” part regularly during refinements or planning sessions.

4. Must I do [THIS] now?

Then there is the actual “this”. Is the “this” the most appropriate and feasible action? Do you know what is driving the enquirer? The key element is not to rush into action mode just because someone has come up with an idea.

In Agile: Scrum and Kanban both push teams to get these aspects out of the way before they start working on something. Refinement sessions are used to clarify all stories and make sure we can actually do all the “thisses”. These tactics can also be used for random questions that come up during a sprint. Bottom line: If they are not clear, just don’t start working on them right away.

5. Must I do this [NOW]?

Last but not least is the “now” part. Now implies urgency. The urgency, however, is perceived by whoever raised the question. Often an action can wait, maybe for you to finish what you are working on, or maybe even longer like a week or more.

In Agile: Again, the Product Owner is the first go-to person to support you in assessing the urgency of the new request. If the assessment is made that the urgency can wait for a week, most times it can be planned and picked up in the next sprint. When organizations are in the midst of the transition to an Agile mindset you often see this ad-hoc pattern recurring. Team members receive requests directly from various stakeholders within the company and not via the Product Owner and Backlog. This indicates that more energy has to be put in the organization of these request flows to fully support the sprint rhythm.

Agile & Common sense

Of course common sense should always prevail and will hopefully be your first advisor. When an important production system is down, there is no time to waste. DevOps Teams often use practices like reserving time for production support or unexpected work to protect their Sprint Goals. A relevant quote from the Scrum guide in the Sprint section: “No changes are made that would endanger the Sprint Goal.” [2]. That is a firm statement. Yet, it also provides guidance to teams to judge whether there is room left in the sprint to help others or to stay focused to the current goal. So, for me these 5 words help me in the coaching of Agile teams to get their priorities straight out in no time. As mentioned in the intro, this approach is not only applicable to Agile teams but useful for everyone with more to do than time available. For another approach you could explore the usage of the Eisenhower Decision Matrix [3].

Side note

Firstly, I don’t take credits for the mnemonic as I did not invent it. A former colleague showed it to me a few years ago. I was not able to find it original roots [4][5]. Secondly, the sentence is a translation from the Dutch “Moet ik dit nu doen?”, which means literary the same – word by word – only in a different order. Since it is an external obligation in the question, the usage of “to have to” in stead of “must“ would improve the sentence’s grammar [6]. I guess the meaning as-is is still solid enough and in this way the original esthetics of the sentence remain intact, instead of “Do I have to do this now?”.

Cheers,
– Sjors Meekels

References

[1] MoSCoW method: en.wikipedia.org/wiki/MoSCoW_method
[2] Sprint Goal: www.scrumguides.org/scrum-guide.html
[3] Eisenhower Decision Matrix: www.artofmanliness.com/2013/10/23/eisenhower-decision-matrix
[4] Origin I Moet ik dit nu doen: lifehacking.nl/persoonlijk-tips/moet-ik-dit-nu-doen (Dutch)
[5] Origin II Moet ik dit nu doen: www.carrieretijger.nl/prioriteiten-stellen (Dutch)
[6] Grammar Must – to have to: www.englishgrammarsecrets.com/musthaveto

Download blog as PDF

This blog is available here:

Filled Under: agile,interim management,scrum Posted on: 14 November 2016

05 Sep 2016

First LeSS Conference – Ever

The first LeSS Conference – Ever
So the first ever LeSS conference was about to take place in Amsterdam. A few former colleagues were planning on going so I was immediately interested as well. The lineup was promising, Bas Vodde and Craig Larman would be present and Gojko Adzic was one of their guest speakers. My knowledge of LeSS was limited to what I had read online as I have not yet been in an organization using LeSS as a scaling framework. Well, you guessed right, I ended up going and in this blog I will share some of my personal highlights of this two-day-event.

Opening and setting
The body organization of LeSS is not a big commercial vehicle which rolls out events like this every few weeks. So things were new and the atmosphere was also newish and therefore relaxing. Cesario had the honor of opening the conference

Story of Less- Bas Vodde
The history of Less may be told during trainings, yet as I heard the story for the first time it was entertaining, recognizable but also refreshing. LeSS is still Scrum, but with a little extra. The focus on Feature teams is an important aspect and needs to be strong. Component teams are not ‘forbidden’, but they mustn’t form the majority. Another interesting point is continuing the Scrum mindset as a framework. The opposite as with RUP, which you have to tailor down, meaning don’t use everything except the parts fitting your own situation. In LeSS it is called “Build Your Method Up”. Bas can probably tell the Story of Less like no one else and the good thing was, he told the story like sitting around a bonfire (just a fire on a video this time). He only showed the slides of the actual story in a total of 20 seconds when he was finishing up. The story was mainly on the core essence and the history of LeSS and not like a mini-course.

Teams and assignments
One of the goals the event organization has was to establish new communities and to enhance the interaction between visitors. The leading mechanism they initiated was the forming of new team who should collaborate on genuine product to be shown at the end of day two. So the entire group of people were gently pushed to form teams by self-organizing. Every visitor had received one or more small buttons indicating a certain capability, e.g. developer, designer, LeSS expert. The goal was to create teams with all the capabilities covered. Yes indeed like a true cross functional team. So this was my team:

The method worked pretty well and it was indeed good for introductions to new people. The actual goal for the assignment wasn’t that clear so most teams lost quite a bit of time on discussions and a few teams dissolved entirely the next day. Yet, experimenting is also a foundation of LeSS so no harm there.

Owning versus Renting Your System – Craig Larman
The title sounds somewhat more relating to a car or house but it made quite an impact on me. When coaching and convincing people to adopt Scrum and to adhere to the rituals correctly you can really see the difference. Some teams start breathing Scrum and start coaching each other- yes and me – when things are not done properly. Stand ups are swift, the board is neat and people respect priority set by the Product Owner. Other teams, are never prepared for anything, forget Dailys when the Scrum Master is not around and follow the coach or Scrum Masters guidance a bit reluctant. The latter team is just Renting Scrum they don’t Own it, the first team does! Craig didn’t use this example, that’s just my reflection of the difference in my daily struggles.

The way to make people buy into an idea and letting them own it was the main thread in his talk. The Why (by Simon Sinek) is solid starter and he then used some more examples based on system theory to let people reach their own opinion and ideas about the way of working. In doing so people are coming up with a part of the solution and start owning it – bit by bit.

Memorable Quotes:

‘No more yak shaving’

‘Underpants gnome profit plan’

So..
The relaxing atmosphere and openness to experiment with the format was nice. Only downside was that it perhaps was a bit stretched and for me personally the last sessions of the second day lost some value. All in all it was very interesting and an excellent place to meet like minded people and increase your network and at the same time increase your knowledge!

Cheers,
– Sjors Meekels

Contributions & References

[1] Conference home: less-large-scale-scrum.com
[2] Program and slides less-large-scale-scrum.com/program.html
[3] Less: less.works
[4] Story of Yak shaving: sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html
[5] Origin of Underpants gnomes: www.youtube.com/watch?v=tO5sxLapAts
[6] Impact Mapping (Gojko Adzic): github.com/facilitation-games/revenue-stream-map

Download blog as PDF

This blog is available here:

Filled Under: agile,scrum,software development Posted on: 5 September 2016

30 Jul 2016

New in the Scrum Guide: Scrum Values

At the begining of the month the new version of the Scrum Guide was introduced. The amount of changes was not big, no surprise there. The Scrum Values themselves were discussed in the webinar and also by Gunther Verheijen, in this post I’ll give a short personal impression on the way the values come into play.

Commitment
Personally I feel the term itself feels a bit unwelcoming, just because of the ‘old’ interpretation of committing to work in a sprint planning. Why reintroduce the term here? I have met several teams who felt uncomfortable committing to anything sometimes. At this point I cannot offer a better word describing the value yet, I am stuck at ‘Willingnes’…..

Focus
At the heart of the Scrum cycle lies the constant focus on the sprint goals. For me I always coach my teams to look beyond the end of the sprint and think about the next release coming up. This helps in understanding the bigger picture and enables the team to make better choices in priorities and approach.

Openness
Openness is the Value equivalent of transparency as one of the pilars of Scrum. For me openness is sharing everything within the team and outside the team. We share the good, the bad and on occasions the ugly. Building up confidence in the idea that sharing and understanding is better than witholding and covering information is key for teams to really connect with the stakeholders.

Respect
As self organizing teams we cannot do without respect for each other. The prime directive used in many retrospectives is clear good example. In my opnion this directive and the Value are the same and are present in the entire sprint and emphasis in the retro is just a small reminder of this value.

Courage
We don’t know or we cannot do something are phrases people are reluctant to use. It is not in our system and often teams stay a bit too close to the things others would like to hear. Yet, we should use them more often to show that we do understand the problems but we just cannot solve them now.

Conclusion

The five values offer an insight in the way we think about transparency and the way the team members collaborate with each other and with stakeholders. So they have value indeed. I do expect a some negative reactions from the people who already miss the real believe in Scrum.

Cheers,
– Sjors Meekels

Contributions & References

[1] Scrum.org Blog: https://blog.scrum.org/updates-scrum-guide-5-scrum-values-take-center-stage
[2] Gunther Verheyen: https://guntherverheyen.com/2013/05/03/theres-value-in-the-scrum-values
[3] Scrum Guide: http://scrumguides.org

Download blog as PDF

This blog is available here:

Filled Under: scrum Posted on: 30 July 2016

24 Jul 2016

Scrum Day Europe 2016

In the first week of July the fifth version of the Scrum Day Europe was held, this was Scrum Day Europe’s first anniversary. Again it was hosted in the beautifully located Pakhuis de Zwijger near the center of Amsterdam. As with a lot of conferences you need to make choices because there are more sessions than time permits you to join. Today I’ll give my thoughts on three I joined and end with an overall opinion.

Keynote – Dave West (Scrum.org)
In his keynote Dave West looked a bit back on the progress Scrum has made in the last years and the challenges that are still present. Especially the getting things really “Done” is one of the big topics this edition and after more than 20 years is still relevant. He also gave a glimpse of the ideas concerning Scrum Studio and setting up a separate organization disentangled from the “old slow organization”. In his afternoon session he went into more detail on this topic, but he did gave the most away in the keynote.

“Saying goodbye to command and control for good” – Christian Brath (Movingimage)
Before this session I never heard of the Berlin company Movingimage but after today the impression will last. During the coffee in the morning I already met Christian and his story intrigued me to go and join his presentation. His company Movingimage has re-invented their business models and therefore also their own organization. They went as far as transforming the entire organization in an Agile setup. They iterated in a few steps to their current model. Of course when flattening the hierarchical structure of your organization you are bound to run into questions like “Who is doing the annual appraisals ?” and “How about conflicts between backlog priorities of different team?”.
Christian was very open and said that not everything is already in a well working definitive state. For me this only indicates that such transformations take years Even after years you will come up with the conclusion that the Agile way of working and transformation will never really stop.

“The future present of Scrum – Are we Done yet?” – Gunther Verheyen (Ullizee-Inc)
I have heard Gunther speak before and have read his book “Scrum wegwijzer”. He can always reduce the complexity of Scrum to the core and focus on the most important subject to discuss. Well today that is getting really working Increments after a sprint. It seems that most organizations still struggle with getting actual working software of the belt at the end of the sprint. Interesting to notice that this is still so hard after 20 years of Scrum. He focused on getting to the root of the problems for not getting to Done, is it the Definition or is the delivery process? In the end it does not matter as long as you involve your Scrum Masters and management and get all impeding affairs out of the way.
His weblog and slides can be found here: The-future-present-of-scrum and here scrum-day-europe-2016-the-future-present-of-scrum. So ask yourself the question, how often does your team or organization deliver working increments? And if not every sprint, what is holding them back?

Wrap up

All in all it was an interesting day with some good sessions. Personally I would have expected to see more people from previous editions and some more acquaintances. At the start of the day a short inventory was done and roughly 80% of the audience was there for the first time and after a steep decline only a handful had visited for over 3 times.

A downside of the way this conference is organized is that you can expect a lot of sessions (co-) presented by people from Prowareness. In itself this is not necessarily a bad thing but bit more variance can be a good thing. The up side is that the people who where present were enthusiastic and I have enjoyed a lot of interesting coffee breaks as well. Enough reasons to come back next year.

See you there in 2017, you can already save the date on July 6!

For more detailed information about this years edition and of next years see: www.scrumdayeurope.com
You can check out a part of the presentation here: www.scrumdayeurope.com/sde-2016
Please note that not all slides are currently present.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,scrum Posted on: 24 July 2016

17 Jul 2016

Scrum – Novice to Ninja

David Green combineert een academische achtergrond in Sociologie en Organisatiekunde met zijn ervaringen in het veld als engineer in het boek Scrum: Novice to Ninja. Het boek is gericht op organisaties die Web- en Mobiele applicaties maken en heeft de professional met relatief weinig ervaring in het gebruik van Scrum op het oog.

Het boek Scrum: Novice to Ninja is tevens het eerste boek wat David Green publiceert. Hij schrijft echter al geruime tijd online artikelen en is een ervaren software engineer. In zijn boek staat de introductie van Scrum centraal en bedient hij de onervaren professional die met Scrum aan de slag wil.

Het verschil met andere boeken die Scrum beschrijven is de specifieke focus op het ontwikkelen van Web en Mobiele applicaties. In hoofdstuk 1 legt Green uit waarom juist deze domeinen zich met uitstek lenen voor de inzet van Scrum. Zo zijn aanpassingen ter ondersteuning van nieuwe browsers of mobiele devices vaak erg urgent. Ook gewenste communicatie-uitingen vragen vaak om ad-hoc werkzaamheden.

De rode draad van het boek is de introductie van Scrum in het fictieve bedrijf WithKittens.com. In hoofdstuk 2 introduceert Green het bedrijf met haar belangrijkste betrokkenen in deze Agile transitie. Vanuit de ogen van bijvoorbeeld een productmanager, een designer of een engineer, laat hij zien wat de huidige motivaties en verwachtingen zijn. Deze persona’s zijn goed gekozen en geven een realistische doorsnede van veel voorkomende teamrollen in organisaties.

Het theoretische kader van Scrum is de boodschap van de hoofdstukken 3, 4 en 5. De beschrijving volgt een logische volgorde van de gedefinieerde rollen, rituelen en gehanteerde artefacten. Wat de beschrijving luchtig houdt, is de speelse manier waarmee het framework in de dagelijkse praktijk wordt gepositioneerd. Concrete dagbeschrijvingen in hoofdstuk 3 geven een informeel en praktisch overzicht van de activiteiten in het leven van een Scrum-practitioner.

In de hoofdstukken 6, 7 en 8 gaat het fictieve bedrijf concreet met Scrum aan de slag en komen de onzekerheden en pijnpunten bij de toepassing aan de orde. Met korte dialogen tussen teamleden en praktische voorbeelden laat Green zien hoe het Scrum spel gespeeld wordt.

Hoofdstuk 9 richt zich op het finetunen en omzeilen van veelvoorkomende problemen. De titel van het hoofdstuk doet vermoeden dat de oplossingen voornamelijk gericht zijn op Web en Mobiele teams. Echter de suggesties en tips zijn in ieder domein van waarde. Welk team is niet gebaat bij ge-timeboxte rituelen of een minimum aan interrupties na de start van een sprint?

Zoals in Scrum retrospectives gebruikelijk is, zo blikt ook Green in hoofdstuk 10 terug. De persona’s, waarmee we eerder kennis hebben gemaakt, kijken terug op hun ervaringen met het gebruik van Scrum. Zij reflecteren op hun eerste reserveringen en geven aan wat zij hebben geleerd. Het meest interessant zijn de overblijvende frustraties en de wijzen hoe de verschillende persona’s hiermee omgaan. Deze zullen voor ervaren Scrum practitioners bekend voorkomen en voor de beginnende professionals een waarschuwing zijn.

Hoofdstuk indeling:
1. Introductie van Scrum
2. Ontmoet het Team
3. Scrum Rollen
4. Scrum Rituelen
5. Scrum Artefacten
6. Het Scrum Contract
7. De levenscyclus van een Story
8. Werken met Scrum
9. Scrum voor Web en Mobile Team
10. Aanpassen aan Scrum

Green hanteert een ruime interpretatie van de officiële Scrum Guides en geeft er zijn eigen twist aan.
Een tekenend voorbeeld is het verschil in terminologie en zijn beschrijving van de Demo’s de Sprint Review in hoofdstuk 4. Is dat erg? Nee, zeker niet. Het geeft de lezer gewoonweg inzicht in de ervaringen en ideeën van de auteur. Het boek is hierdoor wel minder geschikt voor diegenen die zich willen voorbereiden op certificering als Scrum Master.

Conclusie: Scrum – Novice to Ninja is in toegankelijk Engels geschreven en geschikt voor iedereen met weinig ervaring met Scrum en zodoende een prima startpunt. De voorbeelden die de auteur projecteert op de medewerkers van WithKittens.com zijn uit de praktijk gegrepen en heb ik zelf bijna zonder uitzondering ervaren. Met 10 beknopte hoofdstukken in 160 bladzijden is het een prima boek om rustig in een weekend door te nemen.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl. Aangezien het betreffende boek in het Engels is, is een Engelse recensie wellicht passender. Bij voldoende tijd zal ik hem alsnog vertalen.

Cheers,
– Sjors Meekels

Note in English

This book review is in Dutch and is also published on www.managementboek.nl. The book is in English so it would make sense to write an English review. Again, when I do have some spare time I will make a translation

Download blog as PDF

This blog is available here:

Filled Under: agile,book review,scrum,software development Posted on: 17 July 2016

21 Jun 2016

Agile Project Management with Kanban

In zijn boek ‘Agile Project Management with Kanban’ deelt Eric Brechner zijn ervaringen met de introductie en het gebruik van Kanban bij het Microsoft Xbox platform. Hij borduurt voort op de groeiende populariteit van Kanban sinds 2010. Zijn doelgroep bestaat uit professionals van alle disciplines in software engineering met interesse voor praktische toepassing. Lezen en daarna zelf doen is zijn credo.

Voor sommigen zal de naam Eric Brechner bekend klinken, dat klopt. Eric Brechner is de auteur van het in 2007 verschenen boek ‘Hard Code’: een bundeling van interne columns over de softwareontwikkeling binnen Microsoft verschenen onder het pseudoniem I.M. Wright. Nu is hij terug met ‘Agile Project Management with Kanban’ en publiceert hij onder eigen naam. In zijn nieuwe boek staat het gebruik van Kanban bij zijn teams van Xbox bij Microsoft centraal.

Zonder er om heen te draaien wijst Brechner er in de inleiding op dat het boek bedoeld is voor professionals die geïnteresseerd zijn in een praktische toepassing van Kanban. Ben je op zoek naar meer achtergrondinformatie over de theorie en fundamentele uitgangspunten van Kanban, dan zijn er betere alternatieven.

Brechner gebruikt het eerste hoofdstuk om het gebruik van Kanban in een organisatie te introduceren. Het is met name gericht op het overtuigen van management en bevat naast de argumentatie tevens een voorbeeldmemo ter ondersteuning.
In het tweede hoofdstuk neem hij de lezer in 5 stappen mee in het opzetten van Kanban. Hij geeft voldoende informatie en handvatten om direct zelf aan de slag te gaan. Elegant kort is zijn vergelijking tussen Kanban-Scrum-Waterval en de wijze waarop deze technieken chaos beperken in stap 3 van het stappenplan. De uitleg over het gebruik van limieten aan Work in Progress en de werkwijze van het Kanbanbord is helder.
De volgende hoofdstukken behandelen specifieke onderwerpen gericht op verschillende organisatorische kenmerken. Hoofdstuk 3 richt zijn pijlen op het halen van deadlines – een terugkerende uitdaging in softwareontwikkeling – en het informeren van management omtrent planning en de inzet van schattingstechnieken.
Hoofdstuk 4 geeft een korte beschrijving van de introductie van Kanban bij een team dat de Waterval-methode gebruikt. Zonder grote verassingen neemt hij mogelijke weerstanden weg en focust hij zich met name op de voordelen van de transitie van Waterval naar Kanban.
De inhoud van het volgende hoofdstuk roept bij Scrum-professionals een aantal vragen en vermoedelijk enige weerstand op, namelijk het vervangen van Scrum door Kanban. De voordelen van Kanban ten opzichte van Scrum zijn vrij summier beschreven. Brechner waardeert Scrum zeker, hij waardeert Kanban nog meer. Tekenend is zijn statement dat ‘Kanban de volgende evolutie van Scrum is’. Dit is natuurlijk, niet geheel onterecht, voer voor discussies met Scrum-aanhangers.
Hoofdstuk 6 is redelijk technisch ingestoken en geeft een beknopte beschrijving van de inzet van verschillende branching, versioning en deployment strategieën. De interessante link met Kanban zijn de aanpassingen die hij inzet op het Kanbanbord en de gehanteerde flows.
Het opschalen van Kanban naar grotere organisaties, zoals Microsoft, vraagt om extra aanpassingen. Aan dit onderwerp besteedt hoofdstuk 7 aandacht. Brechner tackelt bekende problemen bij opschalen zoals communicatie en afhankelijkheden tussen teams. De verschillende manieren om volgordelijkheden tussen teamactiviteiten inzichtelijk te maken zijn naast leerzaam, ook zeker in andere Agile-frameworks toepasbaar.
Hoofdstuk 8 is geschreven door James Waletzky, een ervaren software engineer die voorheen werkzaam was in de Xbox teams. Hij beschrijft de integratie van het werken aan bugs met de doorontwikkeling van een product. Deze twee aspecten staan vaak op gespannen voet, vandaar de extra aandacht in een apart hoofdstuk. Voor diegenen die in productdevelopment werkzaam zijn, zijn de ‘troubleshooting’ voorbeelden zeer herkenbaar.
Het laatste hoofdstuk, behandelt uitbreiding van Kanban met andere methodes en technieken zoals Lean, Theory of Constraints of Critical Chain. Dit hoofdstuk is met name bedoeld voor meer ervaren teams die de basisflow in de vingers hebben en zoeken naar verdere optimalisaties.

Per hoofdstuk zijn praktische checklist toegevoegd en bij een aantal hoofdstukken zijn interessante vraag-antwoord voorbeelden opgenomen. Met name de voorbeelden bereiden de lezer voor op vragen van mogelijke klanten, managers of teamgenoten. Nuttig om te weten is dat de rekenvoorbeelden en het genoemde memo online beschikbaar zijn. Hiermee heeft de lezer direct één op één de voorbeelden uit het boek te pakken.

Brechner’s achtergrond als engineer verklaart wellicht het veelvuldig gebruik van checklists, tips, formules en voorbeelden. Hoewel de gebruikte formules en voorbeelden niet complex zijn, lees je dit boek waarschijnlijk niet in één adem uit. Dat hoeft ook niet. De gekozen opzet, met hoofdstukken gericht op specifieke situaties, geeft de lezer de mogelijkheid snel door te bladeren naar de voor hem of haar relevante onderdelen.

Heb je behoefte aan een praktische leidraad in Kanban of ben je nieuwsgierig naar het ontwikkelproces bij een top gaming platform & multinational zoals Microsoft – dan ben je met Agile Project Management with Kanban aan het juiste adres.

Cheers,
– Sjors Meekels